Replication进阶(四) 从bug-92252来看GTID复制协议

从bug92252来看GTID复制协议

简介

最近搜索MySQL bug系统，发现5.7.23存在复制相关的bug https://bugs.mysql.com/bug.php?id=92252

大概意思如下
在使用GTID协议协议进行复制时，slave设置了复制错误跳过选项，当出现相应的错误时，并不会中断sql回放线程，于是会出现GTID空洞的现象，这些事务在主库上是执行过的，但是在从库中并没有执行过。那么问题就来了，当主库由于binlog过期时间设置，或者手动purged掉这部分GTID后，如果从机执行stop slave，start slave操作，则IO线程会报GTID被purged掉的错误。

Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'

问题原因

这涉及到基于GTID的复制在建立复制链接是，如何寻找复制起始位点，这部分代码在

Binlog_sender::check_start_file()

master找点的逻辑为

• 将当前所有的binlog文件名加入一个list
• 倒序查看每一个binlog文件中的Previous-GTIDs,判断Previous-GTIDs是否是从机GTID_executed的子集，如果是，则从当前binlog文件开始复制。
• 开始从此文件为起点，开始send_binlog.
• 过滤此文件中每一个存在于从机GTID_executed中的事务。

所以如果master当前保存的binlog的Previous-GTIDs都不是slave GTID_executed的子集，则会报错，无法建立复制链接。

解决办法

解决办法就是在从机上通过set gtid_purged的方式，手动去填补这些空缺。