Linux运维：通过MMM构建MySQL高可用集群系统

Posted 2021-04-08 计算机与网络安全

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Linux运维：通过MMM构建MySQL高可用集群系统相关的知识，希望对你有一定的参考价值。

一次性付费进群，长期免费索取教程，没有付费教程。

教程列表见微信公众号底部菜单 | 本文底部有推荐书籍

ID：Computer-network

双主互备的mysql高可用解决方案通过MySQL的主从复制功能实现了MySQL集群的数据同步功能，同时通过Keepalived实现任意节点故障后自动切换到另一个节点的故障转移功能。这个架构非常适用于对MySQL持续服务要求比较高的场合，但是此方案也有一些缺陷：首先，任意时刻只有一个节点对外提供服务，另一个节点处于数据同步状态，不对外提供任何服务，这在一定程度上浪费了资源；其次，MySQL主从复制支持一主多从架构，这对于读操作比较大的Web业务系统来说，可以将读的压力分散到多个Slave上，而双主互备架构显然没有充分发挥MySQL复制的优势；最后，如果在双主互备的基础上增加多个Slave节点，将会出现问题，因为在Master节点切换到备用Master节点后，多个Slave节点的“Master_Host”无法自动切换到备用Master节点，从而导致整个MySQL高可用架构出现问题。

要解决这些问题其实并不难，通过MMM集群套件（MySQL主主复制管理器）即可轻松实现。本文介绍通过MMM集群套件来构建高性能的MySQL集群系统。

1、MMM高可用MySQL方案简介

MMM高可用MySQL方案是一个通过Perl编写的、基于MySQL主从复制的、成熟完善的MySQL高可用集群解决方案，由一个管理端（monitor）和多个代理端（agent）构成。通过MMM可以实现监控和管理MySQL主主复制和服务状态，同时也可以监控多个Slave节点的复制以及运行状态，并且可以做到任意节点发生故障时实现自动切换的功能。MMM集群方案的出现为MySQL的读、写分离架构的应用提供了一个很好的平台，这是因为MMM集群方案将读IP（reader IP）和写IP（writer IP）从数据库层面提取出来，在业务系统只需调用即可实现读、写分离功能。

虽然MMM是一个MySQL主主复制管理器，但是在整个集群中，同一时刻只有一个Master是可写的，这样做是为了保证数据的完整性和安全性。

MMM套件主要的功能是通过下面三个脚本来实现的。

mmm_mond：这是一个监控进程，运行在管理节点上，主要负责对所有数据库的监控工作，同时决定和处理所有节点的角色切换。

mmm_agentd：这是一个代理进程，运行在每台MySQL服务器上，主要完成监控的测试工作以及执行简单的远端服务设置。

mmm_control：这是一个简单的管理脚本，用来查看和管理集群运行状态，同时管理mmm_mond进程。

MMM集群套件具有良好的稳定性、高可用性和可扩展性，当活动的Master服务器故障以后，备用Master服务器会立刻接管，而其他的Slave服务器也能自动切换到备用Master服务器继续进行同步复制，整个过程无需人为干预。

当然，MMM集群套件也有一定的缺点：首先MMM架构需要多个节点、多个IP，对服务器数量有要求；其次，MMM方案在读、写非常繁忙的业务系统下表现不是很稳定，可能会出现复制延时、切换失效等问题。因此，MMM方案并不太适应于对数据安全性要求很高，并且读、写频繁的环境中。

2、MMM典型应用方案

MMM有多种应用架构，最简单的是两个节点的运行环境，如图1所示。

Linux运维：通过MMM构建MySQL高可用集群系统

图1 MMM双Master节点应用架构

双Master节点的MySQL应用架构与MySQL双主架构完全相同，所不同的是这里的双Master架构是通过MMM管理套件实现的，而双主架构是通过Keepalived实现的。

在正常情况下（系统、网络正常，MySQL服务正常，主从复制正常，没有复制延迟等），Master1有两个虚拟IP（reader IP和writer IP），Master2有一个虚拟IP（reader IP），如果Master1发生故障，那么所有的reader和writer虚拟IP都会被分配给Master2。

在双Master节点的基础上，增加多个Slave节点，即可实现双主多从节点应用架构，如图2所示。

Linux运维：通过MMM构建MySQL高可用集群系统

图2 MMM双主多从节点应用架构

双主多从节点的MySQL架构适合读查询量非常大的业务环境，通过MMM提供的reader IP和writer IP可以轻松实现MySQL的读、写分离架构。此架构通过两个Master实现MySQL写操作的高可用，然后在Master后端又增加了多个Slave节点，所有的Slave节点只能进行读查询操作，而多个Slave节点之间可以通过LVS、HAProxy等负载均衡软件实现MySQL读操作的负载均衡。

MMM套件的优势在于：它不但可以监控两个Master节点的运行状态，还可以监控多个Slave节点的运行状态，任何一个节点出现问题，都会将失败节点对应的虚拟IP自动实现切换到其他健康的节点上，保持读、写服务的连续性和高可用性。

MMM不仅能提供虚拟IP自动转移功能，更重要的是，如果活动的Master节点发生故障，会自动将后端的多个Slave节点转向备用的Master节点继续进行同步复制，整个过程完全不需要手工更改同步复制的配置，这是其他所有MySQL高可用集群方案都不具备的功能。

3、MMM高可用MySQL方案架构

根据上面介绍的MMM应用方案，下面介绍通过MMM集群套件如何实现双主双从节点的典型应用架构，如图3所示。

Linux运维：通过MMM构建MySQL高可用集群系统

图3 双主双从的MySQL高可用集群架构

此架构需要5台独立的服务器，其中一台MMM管理节点，两台MySQL的Master节点，还有两台MySQL的Slave节点，服务器配置环境如表1所示。

Linux运维：通过MMM构建MySQL高可用集群系统

表1 双主双从集群配置环境

MMM双主双从应用架构对应的读、写分离IP列表如表2所示。

Linux运维：通过MMM构建MySQL高可用集群系统

表2 双主双从应用架构读、写分离IP列表

4、MMM的安装与配置

（1）MMM套件的安装

出于安装方便的考虑，这里推荐通过yum源方式进行安装MMM套件，而CentOS的默认源中没有MMM的安装包，因此需要首先安装一个epel的yum源。可以通过http://fedoraproject.org/wiki/EPEL/zh-cn下载与操作系统版本对应的yum源，这里下载的是epel-release-6-8.noarch.rpm，将此RPM文件在MMM集群的所有节点安装即可，过程如下：

[root@Monitor mmm]# rpm -Uvh epel-release-6-8.noarch.rpm

完成yum源安装后，就可以直接安装MMM集群套件了，在Mnoitor节点执行如下命令：

[root@Monitor mmm]# yum -y install mysql-mmm*

在每个MySQL DB节点只需要安装mysql-mmm-agent即可，因此可执行如下命令：

[root@Master1 mysql]# yum -y install mysql-mmm-agent

完成安装后，查看下安装的mysql-mmm版本信息，执行如下命令：

[root@Monitor mmm]# rpm -qa|grep mysql-mmm

mysql-mmm-agent-2.2.1-2.el6.noarch

mysql-mmm-tools-2.2.1-2.el6.noarch

mysql-mmm-2.2.1-2.el6.noarch

mysql-mmm-monitor-2.2.1-2.el6.noarch

这里安装的MMM套件版本为mysql-mmm-2.2.1-2。至此，MMM集群套件安装完成。

（2）MMM集群套件的配置

由于MMM集群套件对数据的读、写进行了严格控制，根据MMM的管理机制，需要首先在所有的MySQL主机上设置read_only参数，也就是在/etc/my.cnf的mysqld配置段中添加如下参数：

read_only = 1

这个参数可以对所有的非临时表进行只读控制，不过它有两个例外，分别是：

对replication threads例外，因此不用担心数据无法复制到这些节点，它可以保证Slave节点能够正常进行复制。

对于拥有超级权限的用户例外，也就是说MySQL的root用户不受这个参数的控制，所以在设置此参数后，需要用一个普通用户进行读写权限的测试才有效果。

完成以上所有设置后，重新启动所有节点的MySQL服务。

要配置MMM，需要先在所有MySQL节点创建除复制账号之外的另外两个账号，即monitor user账号和monitor agent账号。其中，monitor user账号是MMM管理服务器用来对所有MySQL服务器做健康检查的，而monitor agent账号用来切换只读模式和同步Master信息。创建这两个账号的SQL语句为：

GRANT REPLICATION CLIENT ON *.* TO 'mmm_monitor'@'192.168.88.%' IDENTIFIED BY 'monitor_password';
GRANT SUPER,REPLICATION CLIENT,PROCESS ON *.* TO 'mmm_agent'@'192.168.88.%' IDENTIFIED BY 'agent_password';

记住这里设置的账户名和密码，下面配置MMM时会用到。

通过yum源方式安装MMM后，默认配置文件目录为/etc/mysql-mmm。关于MMM的配置主要涉及4个配置文件，分别是mmm_mon.conf、mmm_common.conf、mysql-mmm-agent和mmm_agent.conf，其中，mmm_mon.conf仅在MMM管理端进行配置，主要用于设置一些监控参数；mmm_common.conf文件需要在所有的MMM集群节点进行配置，且内容完全一样，主要用于设置读、写节点的IP及配置虚拟IP；mmm_agent.conf也需要在所有MySQL节点进行配置，用来设置每个节点的标识。

1）配置mmm_common.conf文件

这里首先看一下mmm_common.conf文件的配置，配置好的mmm_common.conf内容如下：

active_master_role writer #当设置这个参数时，集群中所有mysql节点都应该设置‘read_only=1’参数，这样，MMM会根据每个节点的角色进行动态判断，当MMM设置写角色的时候，会自动在可写节点执行‘set global read_only = 0’操作，也就是打开写权限，其他只读的角色保持‘read_only=1’的只读权限

<host default>
cluster_interface eth0 #配置的网络接口，这里不能指定为子接口，如eth0:0
pid_path /run/mysql-mmm-agent.pid #设定PID文件位置
bin_path /usr/libexec/mysql-mmm/ #设定MMM可执行文件路径
replication_user repl_user #设定复制的用户名
replication_password 123456 #设定复制的密码
agent_user mmm_agent #设定更改只读操作的用户
agent_password 123456 #设定更改操作用户的密码
</host>

2）配置mmm_agent.conf文件

接下来看一下mmm_agent.conf文件，此文件非常简单，主要用来定义集群中的主机，在mmm_common.conf文件中使用的db1、db2等名称都是在此文件中定义的。下面给出Master1节点mmm_agent.conf文件的内容：

include mmm_common.conf
this db1

其中，include参数将mmm_common.conf文件引用了进来，this参数指定了Master1节点在MMM集群中对应的主机名为db1，其他节点mmm_agent.conf文件内容依此类推，即Master2节点对应的主机名为db2，Slave1节点对应的主机名为db3，Slave2节点对应的主机名为db4。这里不再给出其他三个节点中mmm_agent.conf文件的内容。

3）配置mmm_mon.conf文件

mmm_mon.conf配置文件仅在MMM管理节点上设置，配置好的mmm_mon.conf文件内容如下：

include mmm_common.conf

</monitor>

<host default>
monitor_user mmm_monitor #monitor user账号
monitor_password 123456 #monitor user密码
</host>
debug 0 #MMM管理端的运行模式，1为debug模式，0为正常模式

4）配置mysql-mmm-agent文件

最后还有一个文件/etc/default/mysql-mmm-agent，它要在MMM集群所有的MySQL节点进行设置，此文件的内容只有一行，确保此文件在所有MySQL节点的内容为：

ENABLED=1

至此，MMM集群的4个主要配置文件介绍完毕。完成所有文件配置后，将mmm_common.conf文件从MMM集群管理节点依次复制到4个MySQL节点即可。这里需要注意的是，MMM集群中所有配置文件的权限最好都设置为640，否则启动MMM服务的时候可能出错。

5、MMM的管理

（1）MMM集群服务管理

MMM集群套件在安装完成后会在系统的/etc/init.d/目录下生成mysql-mmm-monitor和mysql-mmm-agent两个服务管理脚本，其中mysql-mmm-monitor文件用来管理MMM集群控制端的服务启动与关闭，而mysql-mmm-agent负责管理MMM集群中每个agent端（所有Mysql服务节点）服务的启动和关闭。这两个脚本的相关用法如下：

[root@Monitor init.d]# /etc/init.d/mysql-mmm-monitor

Usage: /etc/init.d/mysql-mmm-monitor {start|stop|restart|condrestart|status}

[root@Master1 init.d]# /etc/init.d/mysql-mmm-agent

Usage: /etc/init.d/mysql-mmm-agent {start|stop|restart|condrestart|status}

在完成MMM集群配置后，就可以通过这两个脚本来启动MMM集群，首先在MMM集群管理端启动mysql-mmm-monitor服务，可执行如下命令：

[root@Monitor init.d]# /etc/init.d/mysql-mmm-monitor start

然后在每个agent端依次启动agent服务，执行操作如下：

[root@Master1 init.d]# /etc/init.d/mysql-mmm-agent start

这样MMM集群服务就可以运行了。

（2）MMM基本维护管理

查看集群的运行状态有两种方式，一种是通过MMM集群提供的mmm_control（仅在MMM管理端存在）命令，另一种是查看MMM集群的运行日志信息，MMM集群的运行日志位于每个集群节点的/var/log/mysql-mmm目录下，可通过查看日志文件了解集群的运行状态。这里重点介绍通过mmm_control工具查看和管理MMM集群。

要查看mmm_control工具的用法，执行“mmm_control help”命令即可显示，操作如下：

[root@Monitor init.d]# mmm_control help

Valid commands are:

help #显示帮助信息

ping #测试网络运行状态

show #显示MMM集群中所有节点的状态

checks [<host>|all [<check>|all]] #显示MMM集群中指定节点的详细状态或显示所有节点的详细运行状态

set_online <host> #将一个MMM集群节点设置为online状态

set_offline <host> #将一个MMM集群节点设置为offline状态

mode #显示MMM集群当前的运行模式，有active、manual和passive三种模式，默认是active模式

set_active #切换MMM集群到active模式

set_manual #切换MMM集群到manual模式

set_passive #切换MMM集群到passive模式

move_role [--force] <role> <host> #在互斥模式下切换角色，例如将写操作从db1切换到db2

set_ip <ip> <host> #用来在被动模式下操纵角色

下面列举几个常用的MMM集群维护管理的例子。例如，要查看集群运行状态，可执行如下命令：

[root@Monitor mysql-mmm]# mmm_control show

db1(192.168.88.20) master/ONLINE. Roles: reader(192.168.88.31), writer(192.168.88.30)

db2(192.168.88.21) master/ONLINE. Roles: reader(192.168.88.32)

db3(192.168.88.22) slave/ONLINE. Roles: reader(192.168.88.33)

db4(192.168.88.23) slave/ONLINE. Roles: reader(192.168.88.34)

ONLINE：表示节点运行正常，处于在线状态。

ADMIN_OFFLINE：表示节点是通过手动模式离线的。

HARD_OFFLINE：表示节点处于离线状态，这一般是由于MMM集群脚本执行ping操作失败或检测MySQL失败而切换的一种状态。

AWAITING_RECOVERY：表示等待恢复状态，如果MMM集群设置的是active运行模式，那么此状态将会自动恢复到ONLINE状态。

REPLICATION_FAIL：表示主从复制失败状态，一般是由于复制主线程没有运行导致的。

REPLICATION_DELAY：表示复制日志有延时，一般是由于检查日志失败导致的。

如果要查看MMM集群目前处于什么运行模式，可执行如下命令：

[root@Monitor mysql-mmm]# mmm_control mode

ACTIVE

由输出可知，MMM集群目前运行于active模式，MMM支持active、manual和passive三种模式。

active：表示主动模式，该模式是默认的，即活动的Master发生故障后另一个备份的Master可自动接管故障Master的角色，继续提供服务；如果Slave节点发生故障，其他健康的Slave节点也会自动接管故障Slave节点的服务，继续提供服务。此模式是经常使用的。

manual：表示手动模式，该模式不会执行自动切换操作，如果某个集群节点发生故障，需要手动切换到其他健康的节点。此模式一般用于特殊的场景中。

passive：表示被动模式，在被动模式下，MMM管理端不会改变集群中节点的角色，也不更新状态文件和发送任何信息给每个agent节点，在启动的节点角色发生冲突时将会进入被动模式。此模式一般不用。

如果要查看所有MMM集群节点的运行状态，可执行如下命令：

[root@Monitor mysql-mmm]# mmm_control checks all

db4 ping [last change: 2019/09/13 15:11:34] OK

db4 mysql [last change: 2019/09/13 15:11:34] OK

db4 rep_threads [last change: 2019/09/13 15:11:34] OK

db4 rep_backlog [last change: 2019/09/13 15:11:34] OK: Backlog is null

db2 ping [last change: 2019/09/13 15:11:34] OK

db2 mysql [last change: 2019/09/13 15:11:34] OK

db2 rep_threads [last change: 2019/09/13 15:11:34] OK

db2 rep_backlog [last change: 2019/09/13 15:11:34] OK: Backlog is null

db3 ping [last change: 2019/09/13 15:11:34] OK

db3 mysql [last change: 2019/09/13 15:11:34] OK

db3 rep_threads [last change: 2019/09/13 15:11:34] OK

db3 rep_backlog [last change: 2019/09/13 15:11:34] OK: Backlog is null

db1 ping [last change: 2019/09/13 15:11:34] OK

db1 mysql [last change: 2019/09/13 15:11:34] OK

db1 rep_threads [last change: 2019/09/13 15:11:34] OK

db1 rep_backlog [last change: 2019/09/13 15:11:34] OK: Backlog is null

而要单独查看某个节点的运行状态，可执行如下命令：

root@Monitor mysql-mmm]# mmm_control checks db1

db1 ping [last change: 2019/09/13 15:11:34] OK

db1 mysql [last change: 2019/09/13 15:11:34] OK

db1 rep_threads [last change: 2019/09/13 15:11:34] OK

db1 rep_backlog [last change: 2019/09/13 15:11:34] OK: Backlog is null

从这个输出可以看出，mmm_mond进程会对每个节点执行四项检查，并且确定检查是否成功，这四项检查的含义为：

ping主要用来测试网络可用性。

mysql用来检测MySQL服务器是否运行正常。

rep_threads用来检测MySQL的复制线程是否正常运行。

rep_backlog用来检测MySQL的复制日志是否有挤压。

在这四项检测中，任何一项出现问题，都会进行角色切换操作，MMM集群正是通过这四项健康检查来保证MySQL服务的高可用性。

6、测试MMM实现MySQL高可用功能

为了确保MMM集群已经正常运行，下面重点测试一下MMM所实现的读、写分离功能和故障转移功能。

（1）读、写分离测试

图4 通过写VIP测试MySQL写操作

由上面的操作可知，通过可写的VIP登录了Master1节点，这里创建了一张表mmm_test，并且插入了一条数据。此时可以登录Master2节点、Slave1节点和Slave2节点，查看下数据是否已经同步过去。

接着仍在MySQL远程客户端通过MMM提供的只读VIP登录MySQL集群，测试过程如图5所示。

图5 通过读VIP测试数据同步和读、写限制功能

（2）故障转移功能测试

故障转移分为Master节点故障转移和Slave节点故障转移。为了进行状态比较，这里首先检查下MMM目前的集群运行状态，信息如下：

[root@Monitor mysql-mmm]# mmm_control show

db1(192.168.88.20) master/ONLINE. Roles: reader(192.168.88.31), writer(192.168.88.30)

db2(192.168.88.21) master/ONLINE. Roles: reader(192.168.88.32)

db3(192.168.88.22) slave/ONLINE. Roles: reader(192.168.88.33)

db4(192.168.88.23) slave/ONLINE. Roles: reader(192.168.88.34)

接着，关闭Master1节点的MySQL服务，再次查看MMM集群运行状态，信息如下：

[root@Monitor mysql-mmm]# mmm_control show

db1(192.168.88.20) master/HARD_OFFLINE. Roles:

db2(192.168.88.21) master/ONLINE. Roles: reader(192.168.88.32),writer(192.168.88.30)

db3(192.168.88.22) slave/ONLINE. Roles: reader(192.168.88.31)

db4(192.168.88.23) slave/ONLINE. Roles: reader(192.168.88.34)

从输出信息可知，Master1目前处于HARD_OFFLINE状态，之前在Master1上面运行的写VIP自动切换到Master2，而读VIP自动切换到Slave1。为了验证切换后是否正常，还可以继续执行上面的读、写分离测试，检查一下Master节点切换后，能否正常实现数据的同步功能以及读、写分离的限制。

接着上面的测试继续进行，重新启动Master1节点上的MySQL服务，然后查看MMM集群的运行状态，信息如下：

[root@Monitor mysql-mmm]# mmm_control show

db1(192.168.88.20) master/ONLINE. Roles: reader(192.168.88.31)

db2(192.168.88.21) master/ONLINE. Roles: reader(192.168.88.32),writer(192.168.88.30)

db3(192.168.88.22) slave/ONLINE. Roles: reader(192.168.88.33)

db4(192.168.88.23) slave/ONLINE. Roles: reader(192.168.88.34)

[root@Monitor mysql-mmm]# mmm_control move_role writer db1

OK: Role 'writer' has been moved from 'db2' to 'db1'. Now you can wait some time and check new roles info!

[root@Monitor mysql-mmm]# mmm_control show

db1(192.168.88.20) master/ONLINE. Roles: reader(192.168.88.31), writer(192.168.88.30)

db2(192.168.88.21) master/ONLINE. Roles: reader(192.168.88.32)

db3(192.168.88.22) slave/ONLINE. Roles: reader(192.168.88.33)