点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！
1.2 问题分析
T09:58:31.782548+08:00 0 [Note] [MY-012469] [InnoDB] *** WE ROLL BACK TRANSACTION (1)
T09:59:37.629547+08:00 0 [Warning] [MY-000000] [Repl] Timeout waiting for reply of binlog (file: mysql-bin.021246, pos: 376552623), quick-sync up to file mysql-bin.021246, position 4540811, size 372011812, wait timeout 13858ms.
T09:59:37.629611+08:00 0 [Note] [MY-000000] [Repl] Timeout group[2], the server_id[2551474949] not reply ack.
T09:59:37.629628+08:00 0 [Note] [MY-000000] [Repl] Timeout group[3], the server_id[609298570] not reply ack.
T09:59:37.629636+08:00 0 [Note] [MY-000000] [Repl] Quick-sync master:set err_flag[1,group status is below lwm mode].
T09:59:37.869478+08:00 0 [Note] [MY-000000] [Repl] Quick-sync master:set err_flag[0,group status is ok].
T09:59:37.869923+08:00 0 [Note] [MY-000000] [Repl] group[2] switch from TIMEOUT to ACTIVE at (mysql-bin.021246, 381316999)
T09:59:47.802267+08:00 0 [Note] [MY-000000] [Repl] group[3] switch from TIMEOUT to ACTIVE at (mysql-bin.021251, 1866)
T10:00:02.442986+08:00 0 [Note] [MY-060017] [Server] srv_do_purge purged pages: 7706 takes: 24747.329 ms
T10:00:28.573573+08:00 0 [Note] [MY-012468] [InnoDB] Transactions deadlock detected, dumping detailed information.
T10:00:28.573622+08:00 0 [Note] [MY-012469] [InnoDB] *** (1) TRANSACTION:
对某个多节点复制表做批量插入，此时该事务大小有300M+,在提交该事务时，主DN在同步binlog给备DN，同步等待期间导致低水位。
3.1 问题总结
通过mysql日志观察发现，在主DN同步这个事务的时候，wait timeout 13858ms.导致在等待备机响应的期间处于低水位状态。 解析日志发现，是该时间点对一个运维表做delete和insert操作。 由于这个表是临时表，表分布规则是默认的多节点复制表。所以此事务会涉及4个分片在同时同步binlog给备机。
3.2 解决方案
方法一：
事务同步完成后，自动恢复。
方法二：
业务调整业务逻辑，在插入或者删除时拆分事务，配置10000提交一次。保证每个事务不要过大。 修改业务表结构，调整表分布规则，从多节点复制表调整为单节点复制表。
本文作者：刘传龙(上海新炬中北团队）
本文来源：“IT那活儿”公众号
文章转载自IT那活儿，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
