共计 1587 个字符，预计需要花费 4 分钟才能阅读完成。
作者：胡呈清
爱可生 DBA 团队成员，善于故障剖析、性能优化，集体博客：https://www.jianshu.com/u/a95…，欢送探讨。
本文起源：原创投稿
* 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。
复制异样
在复制过程中，主库产生故障或者网络中断，都会造成 slave io thread 中断，就有可能呈现从库只复制了半个事务的状况。比方主库执行的事务如下：
begin;
insert 1;
insert 2;
commit;从库接管的 binlog 可能只蕴含事务的一部分，比方：
- 状况 1：只蕴含 begin;
- 状况 2：只蕴含 begin;insert 1;
- 状况 3：只蕴含 begin;insert 1;insert 2;
从库的 slave sql thread 回放完这部分 binlog 后，会期待 slave io thread 从主库读取残余的 binlog，而在此之前 sql 线程回放这半个事务，就和咱们手工执行半个事务一样，不会提交也不会回滚。
咱们应该如何应答这种异样呢？
- 当 slave io thread 复原，应该做什么？
- 当 slave io thread 无奈复原，应该做什么？
试验过程
测试方法：
##1. 在从库上用 tc 模仿网络提早，意在使读取 binlog 的速度变慢
tc qdisc add dev eth0 root netem delay 3000ms 3000ms 100%
##2. 在主库执行一个多语句事务
begin;
update t2 set pad='4' where id < 40;
update t2 set pad='5' where id < 50;
update t2 set pad='6' where id < 60;
commit;
##3. 在主库执行 commit 胜利后，立即用 iptables 切断主从之间的网络
iptables -A OUTPUT -d 172.16.21.4 -j DROP
iptables -A INPUT -s 172.16.21.4 -j DROP这样咱们能够在从库上察看到的景象为：
- 其中一个 worker 线程状态是
Waiting for an event from Coordinator，这个状态阐明 work 线程曾经干完活在等 Coordinator（协调线程）调配新的 relay log event，但同时又显示它正在执行update t2 set pad='5' where id < 50，这是矛盾 1：
show slave status输入中，Retrieved_Gtid_Set与Executed_Gtid_Set相等（意味着 sql 线程曾经回放完所有的 relay log），然而上图 worker 线程又正在回放 SQL，这是矛盾 2：
最初咱们通过 relay log 实锤，能够看到这个事务的 relay log 并不残缺，到 update t2 set pad='5' where id < 50; 这个Rows_query event 就完结了：
当 slave io thread 无奈复原
如果 slave io thread 长时间不能复原，那么 sql 线程会因为等不到残余的 binlog，始终无奈提交或回滚，会始终持有这个事务的锁：
如果是主库故障导致的 slave io thread 异样，那很可能会进行主从切换，这个从库晋升为主后，SQL 线程持有的事务锁可能会阻塞业务申请。
此时应该 stop slave 进行 sql 线程，让事务回滚开释锁。须要留神的是：此状况下 stop slave 会期待 60 秒（等 slave io thread 接管事务残余的 binlog），60 秒超时后才会进行 sql 线程：
当 slave io thread 复原
slave io thread 异常中断后，sql 线程是失常工作的，sql 线程执行了局部事务，并且会期待 io 线程发送新的 binlog。slave io thread 线程复原后，如果是基于 GTID 的复制，会从以后 GTID 事务开始从新获取残缺的 binlog，从库会先回滚以后事务，而后再从新回放新收到的 binlog。
