Question

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

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

13.3.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 方案并不太适应于对数据安全性要求很高，并且读、写频繁的环境中。

13.3.2 MMM 典型应用方案

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

图 13-12 MMM 双 Master 节点应用架构

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

在通过 MMM 套件实现的双 Master 架构中，需要 5 个 IP 地址，两个 Master 节点各有一个固定不变的物理 IP 地址，另外还有两个只读 IP 和一个可写 IP，这三个虚拟 IP（2 个 reader IP 和一个 writer IP）不会固定在任何一个节点上，相反，它会在两个 Master 节点之间来回切换，如何切换取决于节点的可用性。例如，活动的 Master（Master1）节点发生故障，它的一个 reader IP 和一个 writer IP 将自动切换到备用 Master（Master2）节点上。

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

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

图 13-13 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 高可用集群方案都不具备的功能。

13.3.3 MMM 高可用 MySQL 方案架构

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

图 13-14 双主双从的 MySQL 高可用集群架构

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

表 13-2 双主双从集群配置环境

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

表 13-3 双主双从应用架构读、写分离 IP 列表

13.3.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 套件配置之前，需要事先配置好 Master1 到 Master2 之间的主主互为同步，同时还要配置好 Master1 到 Slave1、Slave2 之间主从同步。关于 Master1 到 Master2 之间的主主同步，前面章节已经做过介绍，这里不再说明，而 Master1 到 Slave1、Slave2 之间主从同步也非常简单，不做过多介绍。但需要注意的是，在配置 Slave1、Slave2 和主 Master 同步时，“master_Host”的地址要填写 Master1 节点的物理 IP 地址，而不是虚拟 IP 地址。

由于 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   /var/run/mysql-mmm/mmm_agentd.pid        #
设定 PID
文件位置
    bin_path   /usr/libexec/mysql-mmm/                  #
设定 MMM
可执行文件路径
    replication_user       repl_user                    #
设置复制的用户名
    replication_password   repl_password                #
设置复制的密码
    agent_user  mmm_agent               #
设置更改只读操作的用户，这个用户前面已经建立
    agent_password     agent_password   #
设置更改只读操作用户的密码
</host>
<host db1>                      #
设置 db1
的配置信息，db1
会在 mmm_agent.conf
文件中定义
    ip      192.168.88.20       #
设置 db1
的物理 IP
地址
    mode   master               #
设置 db1
的角色为 Master
    peer    db2                 #
设置与 db1
对等的主机名，也就是 db1
和 db2
均为 Master
角色
</host>
<host db2>                      #
设置 db2
的配置信息，db2
会在 mmm_agent.conf
文件中定义
    ip      192.168.88.21       #
设置 db2
的物理 IP
地址
    mode   master               #
设置 db2
的角色为 Master
    peer    db1                 #
设置与 db2
对等的主机名
</host>
<host db3>                      #
设置 db3
的配置信息，db3
会在 mmm_agent.conf
文件中定义
    ip      192.168.88.22       #
设置 db3
的物理 IP
地址
    mode    slave               #
设置 db2
的角色为 Slave
</host>
<host db4>                      #
设置 db4
的配置信息，db4
会在 mmm_agent.conf
文件中定义
    ip      192.168.88.23
    mode    slave
</host>
<role writer>                   #
设置可写角色模式
    hosts  db1, db2             #
设置可执行写操作的主机，这里指定 db1
和 db2
均可写
    ips    192.168.88.30        #
设置可写的虚拟 IP
地址
    mode  exclusive             #
设置角色的模式为互斥，互斥角色只有一个 IP
，并且同一时间
                                #
只能分配给一个主机，一般 writer
角色是 exclusive
模式
</role>
<role reader>                   #
设置可读角色模式
    hosts  db1, db2, db3, db4   #
设置可执行读操作的主机
    ips    192.168.88.31, 192.168.88.32, 192.168.88.33, 192.168.88.34
                                #
设置可读的虚拟 IP
地址，可以有多个
mode  balanced                  #
设置角色的模式为负载均衡，在负载均衡角色中，可以有多个 IP
，
                                #
这些 IP
被均衡动态地分配给多台 MySQL
主机，一般 reader
角色
                                #
是 balanced
模式
</role>

（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>
ip         127.0.0.1    #
为了安全性，设置只在本机监听，mmm_mond
默认监听端口为 9988
    pid_path    /var/run/mysql-mmm/mmm_mond.pid #
设置 mmm_mond
进程 PID
文件位置
    bin_path    /usr/libexec/mysql-mmm          # MMM
可执行文件路径
    status_path  /var/lib/mysql-mmm/mmm_mond.status                                 # MMM
集群的状态文件
    ping_ips     192.168.88.1, 192.168.88.20, 192.168.88.21, 192.168.88.22,
    192.168.88.23 
    #
用于测试网络可用性的 IP
地址列表，只要其中有一个地址能 ping
通，就代表网络正常，这里不要
    #
写入本机的 IP
地址。
    flap_duration       3600    #
抖动的时间范围，默认 3600s
    flap_count          3       #
在抖动的时间范围内，最大的抖动次数
auto_set_online     0           #
是否设置自动上线，如果该值大于 0
，抖动的主机在
                                #
抖动的时间范围过后，则设置自动上线
</monitor>
<host default>
    monitor_user        mmm_monitor      # monitor user
账号，事先已经设置过
    monitor_password    monitor_password # 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 服务的时候可能出错。

13.3.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)

在这个输出中，最左边的 IP 信息是集群节点的物理 IP，然后是 MySQL 主从复制的角色和集群节点的状态，最后是 MMM 集群中读、写角色以及对应的读、写虚拟 IP 地址信息。这里需要注意的是 MySQL 主从复制的角色和集群节点的状态，例如 master/ONLINE 表示主从复制的 Master 角色处于正常的在线状态。在 MMM 集群中，集群节点的状态有如下几种：

- 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: 2014/03/30 13:46:53]  OK
db4  mysql              [last change: 2014/03/30 13:46:53]  OK
db4  rep_threads        [last change: 2014/03/30 14:49:10]  OK
db4  rep_backlog        [last change: 2014/03/30 13:46:53]  OK: Backlog is null
db2  ping               [last change: 2014/03/30 13:46:53]  OK
db2  mysql              [last change: 2014/03/30 13:48:23]  OK
db2  rep_threads        [last change: 2014/03/30 15:16:30]  OK
db2  rep_backlog        [last change: 2014/03/30 13:46:53]  OK: Backlog is null
db3  ping               [last change: 2014/03/30 13:46:53]  OK
db3  mysql              [last change: 2014/03/30 13:46:53]  OK
db3  rep_threads        [last change: 2014/03/30 14:49:10]  OK
db3  rep_backlog        [last change: 2014/03/30 13:46:53]  OK: Backlog is null
db1  ping               [last change: 2014/03/30 13:46:53]  OK
db1  mysql              [last change: 2014/03/30 15:15:49]  OK
db1  rep_threads        [last change: 2014/03/30 13:49:04]  OK
db1  rep_backlog        [last change: 2014/03/30 13:47:36]  OK: Backlog is null

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

[root@Monitor mysql-mmm]# mmm_control  checks db1
db1  ping               [last change: 2014/03/30 13:46:53]  OK
db1  mysql              [last change: 2014/03/30 15:15:49]  OK
db1  rep_threads        [last change: 2014/03/30 13:49:04]  OK
db1  rep_backlog        [last change: 2014/03/30 13:47:36]  OK: Backlog is null

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

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

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

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

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

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

13.3.6 测试 MMM 实现 MySQL 高可用功能

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

1.读、写分离测试

要在任意一个 MySQL 远程客户端通过 MMM 提供的读、写虚拟 IP 地址登录 MMM 集群，测试一下是否实现了数据同步和读、写限制，首先使用 MMM 集群的可写 VIP 远程登录，操作过程如图 13-15 所示。

图 13-15 通过写 VIP 测试 MySQL 写操作

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

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

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

在这个操作过程中，通过只读虚拟 IP 地址“192.168.88.32”登录了 Slave1 主机，并且在 Master1 节点创建的表 mmm_test 已经同步过来。最后尝试在 Slave1 上创建表 mmm_test1 时，发生错误，提示 Slave1 节点设置了只读模式。这刚好实现了读、写分离的限制，由此可知，MMM 集群不但实现了数据的同步，而且通过可写 VIP 及只读 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), reader(192.168.88.33)
  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)

从输出可知，在 Master1 恢复正常后，读 VIP 地址“192.168.88.31”又自动切换到 Master1 节点，而写 VIP 地址“192.168.88.30”却一直留在 Master2 节点。这种机制类似于 Keepalived 中的不抢占功能，由于 MySQL 故障的切换代价很大，所以即使 Master1 恢复正常，写 VIP 地址也不再切换回来，直到 Master2 发生故障时才会再次进行切换。而如果要让写 VIP 地址在 Master1 节点运行，可以手动执行如下切换操作：

[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)
  db4(192.168.88.23) slave/ONLINE.  Roles: reader(192.168.88.34)

这样，MMM 集群又恢复了初始状态。

最后，再测试一下 MMM 集群对 Slave 节点的 MySQL 复制线程的监控和故障转移过程。首先在 Slave1 节点关闭复制线程，操作如下：

[root@Slave1 ~]# mysql -uroot -p
Enter password:
mysql> slave stop;                                                   
Query OK, 0 rows affected (0.02 sec)

接着在 MMM 管理端查看 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.33), reader(192.168.88.32)
  db3(192.168.88.22) slave/REPLICATION_FAIL. Roles:
  db4(192.168.88.23) slave/ONLINE.  Roles: reader(192.168.88.34)

从输出可知，Slave1 的状态变为 REPLICATION_FAIL，同时只读 VIP 切换到 Master2 节点，实现故障的快速转移。如果重新启动 Slave1 上的复制线程，那么 MMM 集群也会立刻检测到，进而再次将只读 VIP 切换到 Slave1 上。