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本身就支持了