mysql 装载dump文件_MySQL手动注册binlog文件造成主从同步异常 该如何解决？

原文：https://www.enmotech.com/web/detail/1/789/1.html (复制链接，打开浏览器即可查看)

导读：本文是作者用MySQL数据库手动注册binlog文件造成主从同步异常后，详述整个分析与解决的过程。

一、问题来源

---

因为某些需求，想将备份的binlog文件恢复到主库并且进行注册，在不关闭主从同步的情况下，他做了如下操作：

1. 将备份的一些binlog文件加入到了binlog日志目录文件中。

2. 修改index文件，加入了这些binlog文件。

3. flush binary logs注册文件。

做完这些操作后，主库确实binlog注册回来了， 但是整个主从环境大量延迟。

二、初次测试

---

测试操作如下：

1. 主库操作，拷贝并且清理binlog

(root:db1@xucl:10:30:22)[(none)]> show binary logs;+---------------------+-----------+| Log_name | File_size |+---------------------+-----------+| mysql-binlog.000035 | 2134 || mysql-binlog.000036 | 845915 || mysql-binlog.000037 | 11735 || mysql-binlog.000038 | 284 || mysql-binlog.000039 | 284 || mysql-binlog.000040 | 284 || mysql-binlog.000041 | 284 || mysql-binlog.000042 | 234 |+---------------------+-----------+12 rows in set (0.00 sec)

拷贝需要清理的binlog到备份目录，即binlog 35、36、37、38。

(root:db1@xucl:10:30:34)[(none)]> purge binary logs to 'mysql-binlog.000039';Query OK, 0 rows affected (0.00 sec)(root:db1@xucl:10:30:49)[(none)]> show binary logs;+---------------------+-----------+| Log_name | File_size |+---------------------+-----------+| mysql-binlog.000039 | 284 || mysql-binlog.000040 | 284 || mysql-binlog.000041 | 284 || mysql-binlog.000042 | 234 |+---------------------+-----------+4 rows in set (0.00 sec)

2. 主库操作，将备份的binlog拷贝回原先的目录并修改index文件进行注册

[root@izbp12nspj47ypto9t6vyez logs]# ll-rw-r----- 1 mysql mysql 2134 5月 20 22:03 mysql-binlog.000035-rw-r----- 1 mysql mysql 845915 5月 20 22:03 mysql-binlog.000036-rw-r----- 1 mysql mysql 11735 5月 20 22:05 mysql-binlog.000037-rw-r----- 1 mysql mysql 284 5月 20 22:06 mysql-binlog.000038-rw-r----- 1 mysql mysql 284 5月 21 10:28 mysql-binlog.000039-rw-r----- 1 mysql mysql 284 5月 21 10:28 mysql-binlog.000040-rw-r----- 1 mysql mysql 284 5月 21 10:28 mysql-binlog.000041-rw-r----- 1 mysql mysql 491 5月 21 10:31 mysql-binlog.000042-rw-r----- 1 mysql mysql 204 5月 21 10:30 mysql-binlog.index

3. 主库操作，主库flush binary logs

(root:db1@xucl:10:32:51)[(none)]> flush binary logs;Query OK, 0 rows affected (0.01 sec)(root:db1@xucl:10:32:57)[(none)]> show binary logs;+---------------------+-----------+| Log_name | File_size |+---------------------+-----------+| mysql-binlog.000035 | 2134 || mysql-binlog.000036 | 845915 || mysql-binlog.000037 | 11735 || mysql-binlog.000038 | 284 || mysql-binlog.000039 | 284 || mysql-binlog.000040 | 284 || mysql-binlog.000041 | 284 || mysql-binlog.000042 | 541 || mysql-binlog.000043 | 234 |+---------------------+-----------+13 rows in set (0.00 sec)

4. 此时，从库操作，show slave status

报错如下：

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Cannot replicate GTID-transaction when @@GLOBAL.GTID_MODE = OFF, at file /storage/single/mysql3306/logs/mysql-binlog.000035, position 194.

5. 错误观察

从这个错误的位点来看，在主库flush binary logs后，视乎主库的DUMP线程又在重新发送老的mysql-binlog.000035这个binlog。报错是因为以前是GTID模式，但是测试的时候已经改为了POSITION模式，是主库DUMP线程在检测主库的GTID Event和从库的GTID模式是否兼容的时候报出来的，如下图

这个错误在这里并不重要，我们只需要知道老的binlog mysql-binlog.000035居然再次发送了。

三、flush binary logs对binlog的操作

---

flush binary logs 至少包含如下操作：

• 获取新的binlog文件名字
• 关闭旧的binlog
• 关闭index file
• 打开index file
• 打开新的binlog
• 将新的binlog加入到indexfile
• 根据参数expire_logs_days判断是否需要进行binlog删除

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

file_info= dir_info->dir_entry; for (i= dir_info->number_off_files ; i-- ; file_info++) { if (strncmp(file_info->name, start, length) == 0 && is_number(file_info->name+length, &number,0)) { set_if_bigger(max_found, number); } }... *next= (need_next || max_found == 0) ? max_found + 1 : max_found;

大概意思就是扫描binlog目录下的binlog文件，获取其序号最高的一个，然后加1。因此即便我们手动修改了index file，flush binary logs不会有问题，因为它实际扫描了binlog文件。同时我们也看到flush binary logs重新加载了index file，这个时候手动修改的index file就生效了，使用show binary logs就能查看到你手动加入的文件了。

栈帧如下：

#0 find_uniq_filename (name=0x7fffec5ec6d0 "/mysqldata/mysql3340/log/binlog