Mysql - 高可用方案之MMM(二)

一、概述

上一篇博客中(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。