MySQL主从严重延迟后迁移Transfer的注意事项

MySQL-Transfer逐渐有一些其他公司的同学在使用，这里会持续更新运维上的注意事项。

      

背景

       正常情况下，若要从原来的主从切换成Transfer 模式，只需要作如下步骤：

1、在slave相同机器上部署一个Transfer，并配置好各种remote_slave参数

2、在slave上stop slave

3、把slave的表结构dump给transfer

4、从slave中查看当前执行到master的位置

5、在transfer执行change master xxxxx; start slave 即可。

 

状况描述

       线上某个项目主从延迟很多天(>7)。由于主库的binlog只保存一周，导致在要切换到Transfer的时候，从slave上show slave status得到的master_log_file在主库已经不存在了。

       这样无法通过上述的步骤5来实现切换到原来的位置。

 

有同学要问，这样的情况下，原来的主从怎么保证最终一致性？

实际上从库上是有两个线程协同工作的，io_thread 已经把主库的更新命令都接收并保存在本地的relay-log了。 只是sql_thread处理速度太慢没有执行这些命令而已。

 

注意

需要特别注意：change master是会删除本地的relay log的。因此在上面的情况下，执行change master要谨慎，以防主库没有binlog的情况下删除备库的relaylog

 

解决方案

       从上面的说明看出，Slave上其实有足够的信息能够重放主库的命令(relaylog).因此在切换到transfer时需要换一个步骤：

1、 在slave相同机器上部署一个Transfer，并配置好各种remote参数

2、在slave上stop slave

3、把slave的表结构dump给transfer

（前面几个步骤不变）

4、将slave上的master.info、 master.info 和 mysqld-relay-bin.* (就是跟从库有关的数据) 都拷贝到transfer的对应目录下

5、在transfer直接执行start slave (重申，不能change master)

 

由于transfer重新启动以后，读到的是从slave上拷贝过来的数据，因此以为是之前自己的io_thread已经读取的数据，start以后就“继续”读取relaylog来更新slave。

 

情况还可能更糟

       如果这时候刚好主库出了点什么问题，导致连都连不了。那么上面改进步骤的第5点，就改成start slave sql_thread，这样tranfer不连主库，先把本地的relaylog都重放一遍。

      

     Btw一下，start slave sql_thread这么犀利的命令不属于transfer patch的代码，MySQL本身就支持了