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

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

??????

背景

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

?

状况描述

?????? 线上某个项目主从延迟很多天(>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时需要换一个步骤：

（前面几个步骤不变）

?

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

?

情况还可能更糟

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

??????

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

?