MMM是:Multi-Master Replication Manager for MySQL,取其中的三个M开头的单词简写。它是mysql多主复制管理器,基于perl实现,关于mysql主主复制配置的监控、故障转移和管理的一套可伸缩的脚本套件(在任何时候只有一个节点可以被写入),MMM也能对从服务器进行读负载均衡,所以可以用它来在一组用于复制的服务器启动虚拟ip,除此之外,它还有实现数 据备份、节点之间重新同步功能的脚本。
MySQL本身没有提供replication failover的解决方案,通过MMM方案 能实现服务器的故障转移,从而实现mysql的高可用。MMM不仅能提供浮动IP的功能,如果当前的主服务器挂掉后,会将你后端的从服务器自动转向新的主服务器进行同步复制,不用手工更改同步配置。从字面来理解就是它有两个master节点,并且实现了这两个master节点的高可用。
MMM主要功能,由下面三个脚本提供:
mmm_mond 负责所有的监控工作的监控守护进程,决定节点的移除(mmm_mond进程定时心跳检测,失败则将write ip浮动到另外一台master)
mmm_agentd 运行在mysql服务器上的代理守护进 程,通过简单远程服务集提供给监控节点
mmm_control 通过命令行管理mmm_mond进程 在整个监管过程中, 需要在mysql中添加相关授权用户,授权的用户包括一个mmm_monitor用户和一个mmm_agent用户,如果想使用mmm的备份工具则还要添加一个mmm_tools用户。
MMM架构的优点
可以兼容不同系列的MySQL来做高可用。比如有MySQL官方社区版本,有percona版本的,有MariaDB版本的MySQL。这样的集群可以可以使用MMM架构来做高可用。
高可用性,扩展性好,出现故障自动切换,对于主主同步,在同一时间只提供一台数据库写操作,保证 的数据的一致性。
当主服务器挂掉以后,另一个主立即接管,其他的从服务器能自动切换,不用人工干预。
MMM架构的缺点
是一种比较老的MySQL高可用实现方式,因为社区不活跃,所以目前已经没有人在维护这个组件了。
只能基于日之点的主从复制集群架构来做高可用,不支持基于GTID的主从复制集群架构。这也是因为社区活跃,没有维护这个组件导致不支持GTID。
数据不能保证100%的一致性,这个是以为它在做故障转移的时候实现的方式所导致的同时也有异步复制机制。如果对于数据需要强一致性,则不能选择MMM高可用架构,可以考虑MHA高可用架构。
monitor节点是单点(故障转移过程中,可能会存在一段时间的数据库不可用),不过这个可以结合keepalived或者haertbeat做成高可用。
至少三个节点,2个master,1个slave,对主机的数量有要求,
在读写非常繁忙的业务系统下表现不是很稳定,可能会出现复制延时、切换失效等问题。
MMM方案并 不太适应于对数据安全性要求很高,并且读、写 繁忙的环境中。
需要实现读写分离,还需要在前端编写读写分离程序,或者结合数据库中间件如mycat来解决。
如何搭建MMM高可用架构
要想实现MMM高可用架构,我们先来搭建一个双主双从的MySQL集群,然后在这个集群的基础上来完成MMM高可用的架构。
第一步部署Mysql(docker)
-----------------------------------
docker run
--net=${网段名}:指定容器运行的时候使用的网段。(network create --subnet=${网段} 网段名)
--hostname ${主机名}:指定容器的主机名称。
--ip ${IP}:指定容器使用的IP地址。
--cap-add NET_ADMIN:
=》默认容器运行的时候,没有增加额外的Linux的功能,这里我们要增加上NET_ADMIN的功能。
--name ${容器名}:指定容器的名称(后续下线操作使用)
-d:以demon进程的方式运行容器
-v ${localPath}:${dockerPath}:把本地的目录挂载到容器中的/etc/mysql/conf.d目录下
-e MYSQL_ROOT_PASSWORD=root:向容器内传入参数,我们指定MySQL数据库root用户的密码也为root。
-e TZ="Asia/Shanghai":向容器内传入参数,这里我们指定的容器中使用的系统的时区为上海时间
-p ${localPort}:${dockerPort}:
=》 我们指定容器中的3306端口,映射到我们本地为指定端口。这样我们在本地访问MySQL服务的时候,就可以通过对应端口来访问。
${镜像名}:
=》这个是我们要运行的容器的名称和版本。从docker hub中自动拉取这个镜像名称和版本到本地,然后再启动这个镜像。
-------------------------------------------------------
1号机IP:172.20.0.11
2号机IP:172.20.0.21
3号机IP:172.20.0.12
4号机IP:172.20.0.22
-------------------------------------
docker ps 展示节点
-------------------------------------
第二部部署Monitor节点(该节点为与其余节点环境一致也部署一个Mysql但不作为数据节点使用仅作为MysqlMMM插件的容器使用)
Monitor机IP:172.20.0.10
-------------------------------------
第三步设置主从配置
主节点(1号、2号机)
create user '${userName}'@'172.20.0.%' identified by '${userName}'
grant replication slave on *.* to '${userName}'@'172.20.0.%'
*****************************如存在历史数据需进行数据同步****************************************
mysqldump
-u${username}
-p${password}
--master-data=2 --master-data ----如果有写log-bin且版本为5.0以上的版本,打开-lock-all-tables
加上 --master-data=1 (输出中会带change master 便于从库搭建)
加上 --master-data=2 (输出中会带注释change master便于从库搭建)
--single-transaction ----一致性备份,保证导出数据一致性
--flush-logs ----开始导出之前刷新日志。
--triggers ----导出触发器
--routines ----导出存储过程以及自定义函数
--events ----导出事件
-B ${DatabaseName} >${sqlName}.sql ----导出几个数据库。参数后面所有名字参量都被看作数据库名。
参数详解可看:https://cloud.tencent.com/developer/article/2034792
************************************************************************************************
从节点(3号、4号机)
change master to master_host='${masterHost}',master_user='${masterSlaveName}'
,master_password='${masterSlavePassword}',master_port='${masterPort}'.......
start slave;
主节点
1号机 2号机相互同步。需检查双机日志偏移量
命令一致
----------------------------------------
第四步下载MMM插件
根据Linux不同 获取MMM插件不同
wget http://deb.debian.org/debian/pool/main/m/mysql-mmm/mysql-mmm_2.2.1.orig.tar.gz
apt-get install
liblog-log4perl-perl
libmailtools-perl
liblog-dispatch-perl
libclass-singleton-perl
libproc-daemon-perl
libalgorithm-diff-perl
libdbi-perl
libdbd-mysql-perl -y //安装依赖包
tar -zxf mysql-mmm_2.2.1.orig.tar.gz
cd mysql-mmm_2.2.1
make install
*********************************************配置文件******************************************
基础配置文件
/etc/mysql-mmm
服务日志文件
/var/log/mysql-mmm/mmm_mond.log//monitor服务日志文件
/var/log/mysql-mmm/mmm_agentd.log//agent日志文件
perl脚本文件
/usr/lib/mysql-mmm/agent
/usr/lib/mysql-mmm/monior
/usr/lib/mysql-mmm/tools
关闭启动脚本
/etc/init.d/mysql-mmm-agent
/etc/init.d/mysql-mmm-monior
***********************************************************************************************
第四步创建MMM用户(全节点)
create user 'mmm_monitor'@'172.20.0.%' identified by '${mmm_monitor}'
grant replication client on *.* to 'mmm_monitor'@'172.20.0.%'
create user 'mmm_agent'@'172.20.0.%' identified by 'mmm_agent'
grant super, replication client,process on *.* to 'mmm_agent'@'172.20.0.%'
第五步修改MMM配置文件
修改mmm_commen.conf
<host default>
#网卡
cluster_interface etg0
pid_path /var/run/mmm_agentd.pid
bin_path /usr/lib/mysql-mmm/
replication_user ${slaveUsername}
replication_password ${slavePassword}
#agent用户名密码
agent_user mmm_agent
agent_password mmm_agent
</host>
<host master1>
ip ${IP}
mode master(主或从)
peer master2(host标签)
</host>
<host master2>
ip ${IP}
mode master(主或从)
peer master1(host标签)
</host>
<host slave1>
ip ${IP}
mode slave(主或从)
</host>
<host slave2>
ip ${IP}
mode slave(主或从)
</host>
#写配置信息
<role writer>
hosts master1,master2
ips ${ips}//虚拟VIP
mode exclusive
</role>
<role writer>
hosts master1,master2,slave1,slave2
ips ${ips}//虚拟VIP
mode balanced
</role>
修改 mmm_agent.conf
cat mmm_agent.conf
include mmm_common.conf
this ${hostName}
monitor节点修改mmm_mon.conf
include mmm_common.conf
<monitor>
ip 127.0.0.1
pid_path /var/run/mmm_mond.pid
bin_path /usr/lib/mysql-mmm/
status_path /var/lib/misc/mmm_mond.status
ping_ips [${NodeIps}]
</monitor>
<host default>
monitor_user mmm_monitor
monitor_password mmm_monitor
</host>
debug 0#关闭DEBUG模式
设置各节点VIP
/usr/lib/mysql-mmm/agent/configure_ip(需安装arp.pm包)
第六步 启动服务
/etc/init.d/mysql-mmm-agent
/etc/init.d/mysql-mmm-monior
start
status
stop
restart
管理命令 mmm_control
参数
help
ping pingMonitor机子
show 状态
check[<host>|all[<check>|all]] 检查
set_online <host> 设置在线
set_offline <host> 设置下线
mode 打印模式
set_active 设置active模式
set_manual 设置manual模式
set_passive 设置passive 模式
move_role [--force] <role><host> 移除规则机子
set_ip <ip><host> 设置role
第七步检查各机子状态
.....
检查主库掉线迁移主库情况
master1 mysql stop
mmm_contorl show
写节点已经修改
MMM高可用验证结果小结:
1.master1节点宕机之后,master2节点会接管master1的所有任务。
2.writer VIP会自动从master1上面转移到master2上面。
3.两个从节点slave1和slave2会自动的把主从同步的链路从master1切换到master2上面。
如果在master1上除了提供写的服务,还提供可读的服务,也就是为其分配了reader VIP,那么当master1宕机后,这个reader VIP不会丢失,会被迁移到其他任意一个节点上。
在master1重启后,在monitor节点通过命令mmm_control set_online master1
设置master1节点上线后,master1节点不会接管现有master2的角色,而是作为一个备用主节点集群中提供服务。此时,只有master2节点宕机后,master1节点才会重新成为主节点的角色。
随着master1和master2节点的宕机和恢复,提供写的VIP会在两个节点上来回切换。