有同学讨论到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可以不改变。
当然，两种都是支持的，胆子大的可以把第一种用起来，免费保修还不行嘛。