乐趣区

关于mysql:技术分享-MySQL从库复制半个事务会怎么样

作者:胡呈清

爱可生 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_SetExecuted_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。

退出移动版