记一次Mysql主从复制延迟,Waiting for dependent transaction to commit
- 一、主从复制延迟现象
- 二、主从复制延迟分析
- 三、主从复制总结
题外话
在官方Mysql 5.6开始引入半同步和多线程复制后,一般情况我们会采用主从复制的方式来解决Mysql数据库的备份或者高可用问题,本文记录为Mysql 5.7.27主从复制采用GTID方式并且开了多线程复制后的一次延迟。
一、主从复制延迟现象
收到主从复制延迟告警
告警内容:(敏感信息做了屏蔽)
Relay_Log_File: mysql-relay-bin.010419
Relay_Log_Pos: 11730698
Relay_Master_Log_File: mysql-bin.005209
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 13754354
Relay_Log_Space: 14690374
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: xxxx
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 53153306
Master_UUID: xxxxxx-3c7f-11e8-969a-005056a16d70
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Waiting for dependent transaction to commit
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: xxxxxxx-3c7f-11e8-969a-005056a16d70:153908122-204096262
Executed_Gtid_Set: xxxxxxx-3c7f-11e8-969a-005056a16d70:1-204095398
收到告警后,立即登陆从库:
在从库show slave status查看到的现象和收到的告警内容一样。
二、主从复制延迟分析
从告警内容可以明显的观察到,主从复制确实有延迟,从Executed_Gtid_Set: xxxxxxx-3c7f-11e8-969a-005056a16d70:1-204095398可以判断出gtid为204095399的事务等待提交。
定位等待提交的事务:
找到主上的binlog日志,用工具mysqlbinlog解析;
解析时,可以一下位置开始Relay_Master_Log_File: mysql-bin.005209,Exec_Master_Log_Pos: 13754354,row格式使用命令:
/data/mysqlbase/mysql3306/bin/mysqlbinlog -vv --base64-output=decode-rows --start-position=13754354 mysql-bin.005209 | less
根据解析binlog日志,可以得出有一个大事务在大量更新数据,导致了延迟。
此情况,我们无需做操作,观察等待此大事务提交完成,主从复制恢复正常。
可以和业务沟通,建议以后避免大事务。
三、主从复制总结
可能出现主从复制延迟的情况:
1.网络延迟较高,导致备库的IO线程等待。
2.备库IO硬件条件较主库差,IO能力不足。
3.主库执行出现大事务,导致出现延时的突刺。
4.备库未开启多线程复制,sql apply存在瓶颈。
5.备机当前会话存在元数据锁等待。
6.无主键表更新。
开启多线程复制的情况
开启多线程回放后,回放控制线程会根据既定的规则,进行并发回放。因此,后续事务如果不可以跟正在回放的事务并发的话,就必须要进行等待。如果开启了slave_preserve_commit_order,进行并发回放的多个事务之间,也要按照和主库上提交的顺序一样,进行提交。
以上所述这也是这两个信息出现的原因。
其中,Waiting for dependent transaction to commit,是当前事务无法和正在回放的事务并发回放出现的等待;
Waiting for preceding transaction to commit,是当前并发回放的事务在进入commit时的flush队列前,必须等到先前事务已经进入flush队列而引起的等待。
哎哟,不错噢! – – – – – – 欢迎指出有误的地方以及补充更好的方法
本文地址:https://blog.csdn.net/Tah_001/article/details/107635837