一、概述
上一篇博客中(https://www.cnblogs.com/ddzj01/p/11535796.html)介绍了如何搭建MMM架构，本文将通过实验介绍MMM架构的优缺点。
二、优点
1. 写vip转移
关掉node1的mysql，看集群会发生什么变化
[root@mysqla ~]# service mysql stop
在monitor查看集群状态
[root@monitor ~]# mmm_control show
在node3中查看
(root@localhost)[(none)]> show slave status\G
可以看到写vip(10.40.16.71)已经漂移到node2，并且node3重新指向了node2
2. 读vip漂移
启动node1的mysql
[root@mysqla ~]# service mysql start
在monitor查看集群状态(可能需要等接近一分钟才能看到下面的状态)
如果长时间是AWAITING_RECOVERY状态，可以去日志中查看原因/var/log/mysql-mmm/mmm_mond.log，确认都没有问题可以使用手工将节点上线"mmm_control set_online db1"
[root@monitor ~]# mmm_control show
可以看到node1又重新加到集群中了，并且有一个读vip已经漂移到node1上了
关闭node3(从库)的mysql
[root@mysqlc ~]# service mysql stop
在monitor查看集群状态
[root@monitor ~]# mmm_control show
可以看到node3(从库)的读vip漂移到了node1上，node3(从库)没有任何读vip了
3. 读延迟
启动node3(从库)的mysql
[root@mysqlc ~]# service mysql start
在monitor查看集群状态
[root@monitor ~]# mmm_control show
在monitor中编辑/etc/mysql-mmm/mmm_mon.conf
添加max_backlog参数，这个参数指的是集群中从库落后于主库多长时间，就将从库上面的读vip摘除。默认是60。
在monitor上重启进程
[root@monitor ~]# service mysql-mmm-monitor restart
在node3(从库)将数据库锁住
(root@localhost)[(none)]> flush tables with read lock;
在node2(主库)对数据库随便做点修改
(root@localhost)[test1]> insert into t1 values(20);
在node3(从库)查看从库状态
(root@localhost)[(none)]> show slave status\G
可以看到从库已经落后了13秒了
在monitor查看状态
[root@monitor ~]# mmm_control checks all
可以看到node3显示ERROR: Backlog is too big
[root@monitor ~]# mmm_control show
可以看到node3的读vip又飘走了。
三、缺点
1. 新主如果落后于旧主，故障切换时，容易造成新主的数据丢失
这个好理解，mysql主从采用的是异步架构，主库的日志如果还没有传到从库上就已经down了，从库就丢失这部分事务了。MMM这种架构也不例外。
2. 事务重复提交的问题
在monitor中编辑/etc/mysql-mmm/mmm_mon.conf，将max_backlog参数删除
在monitor上重启进程
[root@monitor ~]# service mysql-mmm-monitor restart
在node3(从库)将数据库锁释放
(root@localhost)[(none)]> unlock tables;
在monitor查看状态
[root@monitor ~]# mmm_control show 
现在承担写角色的是节点2
先把node1的sql_thread停掉，模拟node1落后于node2的情况(这种情况是指node1已经接收到node2的日志，但是还没有应用)
(root@localhost)[test1]> stop slave sql_thread;
在node2上插入一条数据
(root@localhost)[test1]> insert into t1 values(20);
然后把node2的msyql关闭
[root@mysqlb ~]# service mysql stop
在monitor查看状态
[root@monitor ~]# mmm_control show
可以看到写vip飘到node1上了
再重启node1的slave进程
(root@localhost)[test1]> stop slave;
(root@localhost)[test1]> start slave;
再来查看node1和node3上t1这张表的数据
node1
(root@localhost)[test1]> select * from t1;
node3
(root@localhost)[test1]> select * from t1;
(root@localhost)[test1]> show slave status\G
可以看到新主变成node1，但是node3上面20却有两条，出现了事务重复提交的情况。
3. 从库丢失事务的情况
先把node2的msyql打开
[root@mysqlb ~]# service mysql start
在monitor查看状态
[root@monitor ~]# mmm_control show
在node1把t1表truncate
(root@localhost)[test1]> truncate table t1;
把node3的sql_thread停掉，模拟node3落后于node1的情况(这种情况是指node3已经接收到node1的日志，但是还没有应用)
(root@localhost)[test1]> stop slave sql_thread;
在node1上插入一条数据
(root@localhost)[test1]> insert into t1 values(10);
把node1的msyql关闭
[root@mysqlb ~]# service mysql stop
再重启node3的slave进程
(root@localhost)[test1]> stop slave;
(root@localhost)[test1]> start slave;
查看node3的复制状态
(root@localhost)[test1]> show slave status\G
可以看到节点重新指向了node2
查看各节点的t1数据
node2
(root@localhost)[test1]> insert into t1 values(20);
(root@localhost)[test1]> select * from t1;
node3
(root@localhost)[test1]> select * from t1;
可以看到现在是同步了，但是此时从库已经丢失了原主库的事务，即10这条数据。
四、总结
MMM这种高可用架构比较老了，数据的一致性很难保证，所以在生产上尽量不要使用这种架构。后面将给大家介绍mysql的另一种高可用架构MHA。