stop slave卡住--事务的事件没有复制完整

在文章stop slave卡住，初步介绍了stop slave的问题现象以及一些原因。

以及文章stop slave 卡住模拟–大事务场景中，介绍了大事务场景中，stop slave的模拟。

本文介绍另外一种情况：一个事务的事件没有完整复制到从库。

主从架构中，在主库上更新数据后，会写入binlog，并复制到从库。

在事务型存储引擎中，如innoDB，数据更新以事务为单位。

一个事务通常有很多event组成，例如begin, commit，query, write_rows等等。

在主库上提交一个事务，事件写入binlog，再复制到从库，从库接着开始回放binlog。从库回放binlog，并不是一个事务的所有event都复制过来以后，才开始回放的，而是一边I/O线程接收binlog日志，一边SQL 线程应用binlog日志。

这样，就可能存在一个问题，如果一个事务的event比较多，只将一部分event复制到从库，此时主库故障 或 网络断开，从库上一直无法接收剩余的event，导致SQL线程一直在等待剩余event。

在这个时候，在从库上执行stop slave，SQL 线程会等待，直到超过等待时间（默认60s），然后回滚事务。

基本的排查思路：

1. 查看大事务正在执行的event（预先有大事务监控，可以采集正在执行的event）。
2. 查看从库的错误日志，确定当时从库正在复制的主库的日志位点。使用这个日志位点，在老主库的binlog中查找对应的事件。
3. 分析原因：
   • 如果正在执行的是begin事件，且从库复制位点对应的事件不是commit，则可以得出，导致stop slave 超时的原因是事务的事件没有接收完整。
   • 正在执行的SQL是 正常更新SQL，则导致stop slave超时原因可能是事务比较大，实际执行很耗时，也可能是事件没有接收完整（因为无法确定正在执行的事务与正在复制的事务是否同一个）。