MMM 即 Multi-Master Replication Manager for MysqL:MysqL 多主复制管理器,基于 perl 实现,关于 MysqL 主主复制配置的监控、故障转移和管理的一套可伸缩的脚本套件（在任何时候只有一个节点可以被写入），MMM 也能对从服务器进行读负载均衡，所以可以用它来在一组用于复制的服务器启动虚拟 ip，除此之外，它还有实现数据备份、节点之间重新同步功能的脚本。MysqL 本身没有提供 replication failover 的解决方案，通过 MMM 方案能实现服务器的故障转移，从而实现 MysqL 的高可用。MMM 不仅能提供浮动 IP 的功能，如果当前的主服务器挂掉后，会将你后端的从服务器自动转向新的主服务器进行同步复制，不用手工更改同步配置。这个方案是目前比较成熟的解决方案。
MMM主要功能由下面三个脚本提供：
mmm_mond 负责所有的监控工作的监控守护进程，决定节点的移除(mmm_mond 进程定时心跳检测，失败则将 write ip 浮动到另外一台 master)等等
mmm_agentd 运行在 MysqL 服务器上的代理守护进程，通过简单远程服务集提供给监控节点
mmm_control 通过命令行管理 mmm_mond 进程
在整个监管过程中，需要在 MysqL 中添加相关授权用户，授权的用户包括一个 mmm_monitor用户和一个 mmm_agent 用户，如果想使用 mmm 的备份工具则还要添加一个 mmm_tools用户。
一、MMM的部署实施
1、基本环境
OS:centos7.2（64 位） 数据库系统：MysqL5.7.13
关闭 selinux
配置 ntp，同步时间
2、在所有主机上配置/etc/hosts 文件，添加如下内容：
在 所 有 主 机 上 安 装 perl perl-devel perl-CPAN libart_lgpl.x86_64 rrdtool.x86_64 rrdtool-perl.x86_64 包
#yum -y install perl-* libart_lgpl.x86_64 rrdtool.x86_64 rrdtool-perl.x86_64
注：使用 centos7 在线 yum 源安装
安装 perl 的相关库
#cpan -i Algorithm::Diff Class::Singleton DBI DBD::MysqL Log::dispatch Log::Log4perl Mail::Send Net::Ping Proc::Daemon Time::HiRes Params::Validate Net::ARP
3、在 master1、master2、slave1、slave2 主机上安装 MysqL5.7 和配置复制
master1 和 master2 互为主从，slave1、slave2 为 master1 的从
（1）在每个 MysqL 的配置文件/etc/my.cnf 中加入以下内容， 注意 server-id 不能重复。
master1 主机：
master2 主机：
slave1 主机：
slave2 主机：
注：在完成了对 my.cnf 的修改后，通过 systemctl restart MysqLd 重新启动 MysqL 服务。4 台数据库主机若要开启防火墙，要么关闭防火墙或者创建访问规则。
（2）主从配置（master1 和 master2 配置成主主，slave1 和 slave2 配置成 master1 的从）：
在 master1 上授权：
在 master2 上授权：
（3）把 master2、slave1 和 slave2 配置成 master1 的从库：
在 master1 上执行 show master status; 获取 binlog 文件和 Position 点
在 master2、slave1 和 slave2 执行：
验证主从复制：
master2 主机：
slave1 主机：
slave2 主机：
如果 Slave_IO_Running 和 Slave_sql_Running 都为 yes，那么主从就已经配置 OK 了
（4）把 master1 配置成 master2 的从库:
在 master2 上执行 show master status ;获取 binlog 文件和 Position 点
在 master1 上执行：
验证主从复制：
master1 主机：
如果 Slave_IO_Running 和 Slave_sql_Running 都为 yes，那么主从就已经配置 OK 了
4、MysqL-mmm 配置：
注 ：因为之前的主从复制，以及主从已经是 ok 的，所以我在 master1 服务器执行就 ok 了。
检查 master2 和 slave1、slave2 三台 db 上是否都存在监控和代理账号
注 ：
mmm_monitor 用户：mmm 监控用于对 MysqL 服务器进程健康检查
mmm_agent 用户：mmm 代理用来更改只读模式，复制的主服务器等
5、MysqL-mmm 安装
在 monitor 主机(192.168.31.106) 上安装监控程序
在数据库服务器(master1、master2、slave1、slave2)上安装代理
6、配置 mmm
编写配置文件，五台主机必须一致：
完成安装后，所有的配置文件都放到了/etc/MysqL-mmm/下面。管理服务器和数据库服务器上都要包含一个共同的文件 mmm_common.conf，
active_master_rolewriter#积极的 master 角色的标示，所有的 db 服务器要开启 read_only 参数，对于 writer 服务器监控代理会自动将 read_only 属性关闭。
同时将这个文件拷贝到其它的服务器，配置不变
#for host in master1 master2 slave1 slave2 ; do scp /etc/MysqL-mmm/mmm_common.conf $host:/etc/MysqL-mmm/ ; done
代理文件配置
编辑 4 台 MysqL 节点机上的/etc/MysqL-mmm/mmm_agent.conf
注：这个配置只配置 db 服务器，监控服务器不需要配置，this 后面的 host 名改成当前服务器的主机名。
启动代理进程
在 /etc/init.d/MysqL-mmm-agent 的脚本文件的#!/bin/sh 下面，加入如下内容
source /root/.bash_profile
添加成系统服务并设置为自启动
注：添加 source /root/.bash_profile 目的是为了 MysqL-mmm-agent 服务能启机自启。自动启动和手动启动的唯一区别，就是激活一个 console 。那么说明在作为服务启动的时候，可能是由于缺少环境变量
服务启动失败，报错信息如下
解决方法：
配置防火墙
编辑 monitor 主机上的/etc/MysqL-mmm/mmm_mon.conf
debug 0#debug 0 正常模式，1 为 debug 模式
启动监控进程：
在 /etc/init.d/MysqL-mmm-agent 的脚本文件的#!/bin/sh 下面，加入如下内容
source /root/.bash_profile
添加成系统服务并设置为自启动
启动报错:
解决方法：安装下列 perl 的库
注 ：无论是在 db 端还是在监控端如果有对配置文件进行修改操作都需要重启代理进程和监控进程。MMM 启动顺序：先启动 monitor，再启动 agent
检查集群状态：
如果服务器状态不是 ONLINE，可以用如下命令将服务器上线，例如：
#mmm_controlset_online 主机名
例如：[root@monitor1 ~]#mmm_controlset_onlinemaster1
从上面的显示可以看到，写请求的 VIP 在 master1 上，所有从节点也都把 master1 当做主节点。
查看是否启用 vip
在 master2，slave1，slave2 主机上查看主 MysqL 的指向
二、MMM 高可用性测试：
服务器读写采有 VIP 地址进行读写，出现故障时 VIP 会漂移到其它节点，由其它节点提供服务。
首先查看整个集群的状态，
模拟 master1 宕机，手动停止 MysqL 服务，观察 monitor 日志,master1 的日志如下：
查看群集的最新状态
从显示结果可以看出 master1 的状态有 ONLINE 转换为 HARD_OFFLINE，写 VIP 转移到了master2 主机上。
检查所有的 db 服务器群集状态
从上面可以看到 master1 能 ping 通，说明只是服务死掉了。
查看 master2 主机的 ip 地址：
启动 master1 主机的 MysqL 服务，观察 monitor 日志,master1 的日志如下：
从上面可以看到 master1 的状态由 hard_offline 改变为 awaiting_recovery 状态
用如下命令将服务器上线：
可以看到主库启动不会接管主，只到现有的主再次宕机。
总结：
优点：高可用性，扩展性好，出现故障自动切换，对于主主同步，在同一时间只提供一台数据库写操作，保证的数据的一致性。当主服务器挂掉以后，另一个主立即接管，其他的从服务器能自动切换，不用人工干预。
缺点：monitor 节点是单点，不过这个你也可以结合 keepalived 或者 haertbeat 做成高可用;至少三个节点，对主机的数量有要求，需要实现读写分离,还需要在前端编写读写分离程序。在读写非常繁忙的业务系统下表现不是很稳定，可能会出现复制延时、切换失效等问题。MMM 方案并不太适应于对数据安全性要求很高，并且读、写繁忙的环境中。
适用场景:
MMM 的适用场景为数据库访问量大，并且能实现读写分离的场景
(1)master2 备选主节点宕机不影响集群的状态，就是移除了 master2 备选节点的读状态。
(2)master1 主节点宕机，由 master2 备选主节点接管写角色，slave1,slave2 指向新 master2主库进行复制，slave1,slave2 会自动 change master 到 master2.
(3)如果 master1 主库宕机，master2 复制应用又落后于 master1 时就变成了主可写状态，这时的数据主无法保证一致性。
如果 master2,slave1,slave2 延迟于 master1 主，这个时 master1 宕机，slave1,slave2 将会
等待数据追上 db1 后，再重新指向新的主 node2 进行复制操作，这时的数据也无法保证同步的一致性。
(4)如果采用 MMM 高可用架构，主，主备选节点机器配置一样，而且开启半同步进一步提高安全性或采用 MariaDB/MysqL5.7 进行多线程从复制，提高复制的性能。
来源：MySQL高可用——MMM - 腾讯云开发者社区-腾讯云
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
