一、概述
本文将介绍mysql的MMM(Master-Master replication manager for MySQL)方案。官方文档地址：https://mysql-mmm.org/start.html
MMM架构由三台mysql服务器(两主一从)和一台监控节点组成，主库只有一台能对外提供写服务，另外一台主和从只对外提供读服务。当提供写服务的主库服务器发生故障时，能自动将写的vip漂移到另外一台写库上，并将从库重新指向另一台写库，实现高可用。
写库故障发生前：
写库故障发生后：
二、节点介绍
本次实验采用4台虚拟机，操作系统版本Centos6.10，mysql版本5.7.25
monitor 10.40.16.60 监控 监控集群
node1 10.40.16.61 主库 提供写服务
node2 10.40.16.62 主库 提供读服务
node3 10.40.16.63 从库 提供读服务
还须预留4个vip，不用手工配置，这里先提一下，后面的安装步骤用得到
10.40.16.71 写vip
10.40.16.72 读vip
10.40.16.73 读vip
10.40.16.74 读vip
三、安装
1. 配置双主一从
其中node1与node2互为主从，node3作为node1的从。具体的复制搭建这里就省略，要是这都不会，那么该文章对你就没意思了。顺便安利一个自己写的mysql一键安装脚本https://www.cnblogs.com/ddzj01/p/10678296.html
注明：集群中使用的复制账号为repl，密码是'123456'
node1(10.40.16.61)
(root@localhost)(none)]> show slave statusG
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.40.16.62
Master_User: repl
node2(10.40.16.62)
(root@localhost)[(none)]> show slave statusG
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.40.16.61
Master_User: repl
node3(10.40.16.63)
(root@localhost)[(none)]> show slave statusG
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: 10.40.16.61
Master_User: repl
可以看到node1和node2互为主备，node3作为node1的备
2. 下载扩展包(node1&node2&node3&monitor)
wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm
rpm -ivh epel-release-latest-6.noarch.rpm
编辑文件/etc/yum.repos.d/epel.repo
将该文件的第三行取消注释，第四行添加注释，如下所示
3. 安装MMM包
每个数据库节点(node1&node2&node3)
yum install -y mysql-mmm-agent.noarch
监控节点(monitor)
yum install -y mysql-mmm-*
4. 创建相关账号
在node1中创建以下账号
监控账号(监控数据库状态)
(root@localhost)[(none)]> grant replication client on *.* to 'mmm_monitor'@'%' identified by '123456';
代理账号(MMM代理)
(root@localhost)[(none)]> grant super, replication client, process on *.* to 'mmm_agent'@'%' identified by '123456';
5. 修改配置文件
所有中文的注释是要修改的地方，注意不要在配置文件中写任何注释
在monitor中编辑/etc/mysql-mmm/mmm_mon.conf
在monitor中编辑/etc/mysql-mmm/mmm_common.conf，传给其它三个节点，内容都一致
scp /etc/mysql-mmm/mmm_common.conf 10.40.16.61:/etc/mysql-mmm/
scp /etc/mysql-mmm/mmm_common.conf 10.40.16.62:/etc/mysql-mmm/
scp /etc/mysql-mmm/mmm_common.conf 10.40.16.63:/etc/mysql-mmm/
在node1&node2&node3中编辑/etc/mysql-mmm/mmm_agent.conf，更改'this db1'，与mmm_common保持一致
6. 启动
node1&node2&node3
[root@mysqla ~]# service mysql-mmm-agent start
[root@mysqlb ~]# service mysql-mmm-agent start
[root@mysqlc ~]# service mysql-mmm-agent start
monitor
[root@monitor ~]# service mysql-mmm-monitor start
7. 查看
在monitor中
[root@monitor ~]# mmm_control show # 查看集群状态
[root@monitor ~]# mmm_control checks all # 查看更加具体的信息
四、MMM优缺点
优点：
1. 提供读写vip
2. 提供从服务器的延迟监控，在从服务器出现大量的主从延迟或主从链路中断时，可以把这台从服务器上的读的vip，飘移到集群中其它正常的节点上
3. 提供主数据库故障转移后从服务器对新主的重新同步功能
缺点：
1. 发布时间较早，文档最后更新的时间是2012年，存在一些bug，并且不支持gtid服务功能
2. 没有读负载均衡的功能
3. 进行主从切换时，新主如果落后于旧主，容易造成新主的数据丢失。如果从库落后于旧主，从库指向新的主库的时候，也会造成从库部分数据丢失。
4. 如果从服务器的日志较新主的服务器日志新，那么就是主从不一致的，会出现事务重复提交。
五、实验
关于mmm的实验请看下一篇博客(https://www.cnblogs.com/ddzj01/p/11543090.html)