mysql主从复制强事务_记一次Mysql主从复制延迟，Waiting for dependent transaction to commit...

记一次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

如您对本文有疑问或者有任何想说的，请点击进行留言回复，万千网友为您解惑！