MMM（Multi-Master Replication Manager for MySQL）
是基于双Master结构，后面接N台Slave
安装很简单，官网提供了很详细的安装文档：http://mysql-mmm.org/mmm2:guide
3台环境做测试
M1和M2互为主从，M1是S1的主。
服务都起来后，状态如下：
[root@M1 mysql-mmm]# mmm_control show
M1(192.168.8.25) master/ONLINE. Roles: writer(192.168.8.51)
M2(192.168.8.26) master/ONLINE. Roles:
slave1(192.168.8.27) slave/ONLINE. Roles: reader(192.168.8.52)
M1提供写，slave1提供读，192.168.8.51和52都是虚拟VIP
场景一，Master宕机，切换
模拟M2同步延时，S1同步无延时
在M2上lock tables table1 read; （把table1表给锁住，这样在M1上更新table1表时，M2就会有延时）
然后把M1的MySQL关闭，VIP按照正常逻辑应该漂移到S1上，但在这里，作者的逻辑是要切换到同级别的主上，也就是M2，永远不会切换到比他身份低的S1从机上面去，即使它没有延时。
在漂移到M2上，必须要等到同步追完才可以切，否则就在那里等待，他利用的是这个函数
MASTER_POS_WAIT，只有Slave执行完全部relay log，才释放锁。
如果延时很大，想生切，只能人工kill到select MASTER_POS_WAIT() 这个进程id
S1会自动指向M2，自动执行change master to M2，那个软件就会自动记录M2上的点。
[root@M1 mysql-mmm]# mmm_control show
M1(192.168.8.25) master/HARD_OFFLINE. Roles:
M2(192.168.8.26) master/ONLINE. Roles: writer(192.168.8.51)
slave1(192.168.8.27) slave/ONLINE. Roles: reader(192.168.8.52)
======================================================
把M1的MySQL进程启动起来，
[root@M1 mysql-mmm]# mmm_control show
M1(192.168.8.25) master/ONLINE. Roles:
M2(192.168.8.26) master/ONLINE. Roles: writer(192.168.8.51)
slave1(192.168.8.27) slave/ONLINE. Roles: reader(192.168.8.52)
VIP还在M2上，并不会因M1修好了，会再漂移过去。