MySQL手动注册binlog文件造成主从异常的原因

一、问题来源

有一个朋友@水米田 问我，基于POSITION的主从。他做了如下的操作

将备份的一些binlog文件加入到了目录中
修改index文件，加入了这些binlog文件
flush binary logs
然后整个主从环境大量延迟。

二、朋友的测试

下面是另外一个朋友@徐晨亮的测试：

三、现象说明

从整个测试来看，MySQL视乎将手动注册的文件进行了传输和应用。报错是因为这个库以前是GITD_MODE=ON的，但是测试的时候已经关闭了GTID_MODE，改为了POSITION的模式，这个报错是因为DUMP线程会进行检测：

这个图来自我新写的一个系列（暂时还没发布，大概年底才能写好）。不管怎么说，DUMP线程已经在开始传输老的binlog文件了。那么原因是什么呢？下面我们将进行解释。

四、flush binary logs对binlog的操作

flush binary logs 将包含如下操作：

• 获取新的binlog文件名字
• 关闭旧的binlog
• 关闭index file
• 打开index file
• 打开新的binlog
• 将新的binlog加入到indexfile

具体可以参考函数MYSQL_BIN_LOG::new_file_impl。其中要说明一下获取新的binlog文件名字是通过函数find_uniq_filename实现的，其中包含如下代码：

大概意思就是扫描index file文件里面的binlog文件，获取其序号最高的一个，然后加1。栈帧如下：

因此即便我们手动修改了index file，flush binary logs却不会有问题，因为它实际扫描了index file文件。
同时我们也看到flush binary logs重新加载了index file，这个时候手动修改的index file就生效了，使用show binary logs就能查看到你加入的文件了。

五、主从问题的产生

binlog切换后，DUMP线程也需要读取下一个binlog文件。我们来看看它是怎么确认读取哪一个文件的。

在函数sender.run()中可以找到循环每个binlog文件的代码。下面一句是寻找下一个binlog文件：

mysql_bin_log.find_next_log 包含的代码：

我们能够看到DUMP线程并没有实际扫描整个index文件，而是通过一个index文件的偏移量进行读取。如果手动修改index文件那么偏移量就出现了错乱。因此DUMP发送的下一个文件将是不确定的。因此出现了发送手动注册的binlog文件给从库的现象，这种情况下可能出现下面情况：

1. 如果是GTID_MODE 关闭，使用POSITION那么这种情况一定报错，比如重复的行。
2. 如果是GTID_MODE 和AUTO_POSITION=1，那么DUMP线程会进行GTID的过滤不发送，因为Event不发送所以延迟会持续一段时间为0。
3. 如果是GTID_MODE 和AUTO_POSITION=0，那么SQL线程应用GITD_EVENT的时候会进行过滤，延迟可能出现很大的情况。

尽管GTID可能可以屏蔽这种问题，但是DUMP线程已经在考虑发送老的binlog文件了，这是不合适的。

六、purge binary logs能够维护这个偏移量

为什么purge binary logs不会出现问题呢，因为在purge binary logs的语句下，会维护这个偏移量如下：

我们可以看到linfo->index_file_offset -= m_purge_offset;这样一个语句。下面是栈帧：

七、测试POSITION模式下的报错

1、 环境

2、执行一个语句

主库：

从库：

这个时候DUMP线程index file偏移指针如下：

3、主库执行purge binary logs

做之前拷贝原有binlog.000001为binlog.000001bak因为等会要拷贝回去

因为purge binary logs命令会维护偏移指针，这个时候DUMP线程的index file偏移指针如下：

4、手动更改

将binlog.000001bak拷贝为binlog.000001，然后修改index file将binlog.000001加入回去，然后flush binary logs如下：

手动完成这个工作并不会维护DUMP线程的index file偏移指针，因此如下：

就这样DUMP线程重新发送了一次binlog.000002的内容，POSITION的从库只能报错了如下：

八、总结

这种操作非常不规范，如果实在要这么做考虑如下步骤：

• 关闭全部的从库
• 手动注册binlog文件，修改index 文件
• flush binary logs
• 启动从库

这种情况下将会重新初始化DUMP的偏移量指针，应该是没有问题的。还是尽量不要考虑这么做。

以上就是MySQL手动注册binlog文件造成主从异常的原因的详细内容