有同学讨论到Transfer能否支持双主结构，答案是支持的，这里简要描述下。

背景

       Transfer既可以当作主从库之外的工具来用，也可以本身充当slave的角色。本文分别描述在这两种使用场景下的部署结构和切换动作。 

Slave模式

a)      结构

这个就是最简单的双主啦，Transfer呢？代码直接写到这两个Master里面啦，所以他们就是Transfer.

b)      切换

DBA同学就用你最熟悉的切换过程去操作。

1)      停止对Master1的更新
2)      确定数据完全同步
3)      将更新引Master2

 这里由Transfer的机制保证步骤2)的时间会很短（因为无延迟）。

工具模式

a)      结构

    如果你比较担心数据安全，怕这个patch作为直接充当master1和master2会有风险，（这是负责任的态度！），就用上图表示的结构。

       其中Transfer1(T1)和Master1(M1)在同一个机器上，(Transfer1)T2和(Master)M2共同在另外一个机器上。

    斜线表示主从关系，T1是M2的从库，T2是M1的从库。
    垂直线表示更新关系，T1收到的同步命令用与更新M1， T2更新M2

b)      切换

切换过程跟第一种模式的一模一样。 

小结

       两种模式的取舍上，第一种运维比较简单，但是风险比较大，如果Transfer有bug，要更新版本，或者要换会原来的主从时，必须得重启Master1和Master2，这种操作并不是所有的系统都能容忍。

       第二种模式我比较推荐。好处有以下几个：

1、Transfer本身不带数据，就算coredump了也不会影响数据服务。同步过程自然要切换回原来的主从方法，就让M1跟M2直连。

（看官问：怎么你这推广东西的说来说去不是bug就是coredump的？

  笔者答：虽然我已经做了自认为足够的测试，但风险总要说明，这是负责任的态度，不然回头你用了把数据服务搞挂，跨省我，咋整？）

2、Master要升级版本（比如你以后要升级成5.6），Transfer可以不改变。

  当然，两种都是支持的，胆子大的可以把第一种用起来，免费保修还不行嘛

建议继续学习：

1. 关于IO的同步,异步,阻塞,非阻塞    (阅读：14481)
2. mysql 主从同步原理    (阅读：5711)
3. 消息分发的同步均衡策略    (阅读：5033)
4. 五款最好的免费同步软件    (阅读：3860)
5. 大量小文件的实时同步方案    (阅读：3728)
6. MySQL5.5复制/同步的新特性及改进    (阅读：3724)
7. redis源代码分析 - replication    (阅读：3416)
8. rsync主动同步代码    (阅读：3128)
9. 三款面向 Amazon S3 的开源文件同步工具之对比    (阅读：3079)
10. truncate table 不能复制到从库    (阅读：2727)