基于MMM搭建MySQL Replication集群高可用架构

林大鹏 2020-02-01

MMM介绍

MMM是Multi-Master Replication Manager for MySQL的缩写,它是MySQL提供的一个多主复制管理器,其核心是使用perl语言编写的一组脚本。实际上MMM是比较早期甚至有点老的一种用于构建高可用MySQL架构的方式,但因其还有一定的应用场景,所以本文将会演示一下如何搭建一个MMM架构。

MMM 由两个组件组成:

  • monitor:监控集群内数据库的状态,在出现异常时发布切换命令,一般和数据库分开部署
  • agent:运行在每个 MySQL 服务器上的代理进程,monitor 命令的执行者,完成监控的探针工作和具体服务设置,例如设置 VIP、指向新同步节点

MMM的主要作用:

  • 监控和管理MySQL的主主复制拓扑,并在当前的主服务器发生故障时,进行主和主备服务器之间的主从切换和故障转移等工作

MMM提供了什么功能:

  • MMM可以监控MySQL主从复制健康情况,包括mysql服务器的状态、从库拷贝活动的状态等
  • 可以在主库出现宕机时进行故障转移,并自动配置其他从库对新主库的复制
  • 为主库提供了一个写虚拟IP,在主从服务器出现问题时可以自动迁移虚拟IP
  • 当配置多个从库时,可配置多个虚拟读IP,配合第三方负载均衡软件(如LVS),实现负载均衡功能

MMM对于主备切换后如何让从库同步日志点:

  • MMM对于这方面的处理并不安全,只是简单粗暴地让从库同步新主库的当前日志点,所以在一个繁忙的系统中使用MMM很有可能会对数据造成丢失的情况

动手搭建MMM架构

本文要搭建的MMM架构如下:
基于MMM搭建MySQL Replication集群高可用架构

以上述架构为例,描述一下故障转移的流程,现在假设 Master1 宕机:

  1. Monitor 检测到 Master1 连接失败
  2. Monitor 发送 set_offline 指令到 Master1 的 Agent
  3. Master1 Agent 如果存活,下线写 VIP,尝试把 Master1 设置为 read_only=1
  4. Moniotr 发送 set_online 指令到 Master2
  5. Master2 Agent 接收到指令,执行 select master_pos_wait() 等待同步完毕
  6. Master2 Agent 上线写 VIP,把 Master2 节点设为 read_only=0
  7. Monitor 发送更改同步对象的指令到各个 Slave 节点的 Agent
  8. 各个 Slave 节点向新 Master 同步数据

从整个流程可以看到,如果主节点出现故障,MMM 会自动实现切换,不需要人工干预,同时我们也能看出一些问题,就是数据库挂掉后,只是做了切换,不会主动补齐丢失的数据,所以 MMM 会有数据不一致性的风险。

搭建MMM架构所需的资源说明:

名称数量说明
Master服务器2用于主备模式的主主复制配置
Slave服务器0-N可以配置0台或多台从服务器,但不建议太多
监控服务器1安装MMM用于监控MySQL复制集群
IP地址2*(n+1)n为MySQL服务器的数量
监控用户1用于监控数据库状态的MySQL用户(至少拥有replication client权限)
代理用户1用于MMM代理的MySQL用户(至少拥有superreplication clientprocess权限)
复制用户1用于配置MySQL主从复制的用户(至少拥有replication slave权限)

本文中所使用的机器说明:

名称IP角色
master-01192.168.190.146主库
master-02192.168.190.148备库
slave-01192.168.190.149从库
manager192.168.190.147集群管理器(MMM)

环境版本说明:

  • 操作系统版本:CentOS 7
  • MySQL版本:8.0.19
  • MMM版本:2.2.1

另外的说明:

  • 会来了解MMM架构的小伙伴们想必都已经掌握了MySQL的安装方式,而且介绍MySQL的安装也有很多文章,所以本文为了减少不必要的篇幅就不演示MySQL的安装了,文中所用到的机器都已经提前安装好了MySQL。

配置主主复制及主从同步集群

1、在master-01master-02上使用如下语句分别创建用于主主复制的MySQL用户:

create user ‘repl‘@‘%‘ identified with mysql_native_password by ‘Abc_123456‘;
grant replication slave on *.* to ‘repl‘@‘%‘;
flush privileges;
  • Tips:创建好账户后,最好使用该账户在两个节点互相登录一下,以确保账户是可用的

2、修改master-01上的MySQL配置文件:

[ ~]# vim /etc/my.cnf
[mysqld]
# 设置节点的id
server_id=101
# 开启binlog,并指定binlog文件的名称
log_bin=mysql_bin
# 开启relay_log,并指定relay_log文件的名称
relay_log=relay_bin
# 将relaylog的同步内容记录到binlog中
log_slave_updates=on

master-02的配置文件中也是添加一样配置,只不过server_id不一样:

[ ~]# vim /etc/my.cnf
[mysqld]
server_id=102
log_bin=mysql_bin
relay_log=relay_bin
log_slave_updates=on

接着是配置slave-01,由于该节点不是作为备库存在,而只是单独的从库角色,所以不需要开启log_slave_updates参数:

[ ~]# vim /etc/my.cnf
[mysqld]
server_id=103
log_bin=mysql_bin
relay_log=relay_bin

完成以上配置文件的修改后,分别重启这三个节点上的MySQL服务:

[ ~]# systemctl restart mysqld
[ ~]# systemctl restart mysqld
[ ~]# systemctl restart mysqld

配置master-02master-01的主从关系

进入master-01的MySQL命令行终端,通过如下语句查询master-01当前正在使用的二进制日志及当前执行二进制日志位置:

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql_bin.000001 |      155 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+

记录其中的FilePosition的值,然后进入master-02的MySQL命令行终端,分别执行如下语句:

mysql> stop slave;  -- 停止主从同步
mysql> change master to master_host=‘192.168.190.146‘, master_port=3306, master_user=‘repl‘, master_password=‘Abc_123456‘, master_log_file=‘mysql_bin.000001‘, master_log_pos=155;  -- 配置master-01节点的连接信息,以及从哪个binlog文件的哪个位置开始复制
mysql> start slave;  -- 启动主从同步

配置完主从关系后,使用show slave status\G;语句查看主从同步状态,Slave_IO_RunningSlave_SQL_Running的值均为Yes才能表示主从同步状态是正常的:
基于MMM搭建MySQL Replication集群高可用架构


配置master-01master-02的主从关系

为了实现主主复制,master-01master-02需要互为主从关系,所以还需要配置master-01master-02的主从关系。进入master-02的MySQL命令行终端,通过如下语句查询master-02当前正在使用的二进制日志及当前执行二进制日志位置:

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql_bin.000001 |      155 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+

记录其中的FilePosition的值,然后进入master-01的MySQL命令行终端,分别执行如下语句:

mysql> stop slave;
mysql> change master to master_host=‘192.168.190.148‘, master_port=3306, master_user=‘repl‘, master_password=‘Abc_123456‘, master_log_file=‘mysql_bin.000001‘, master_log_pos=155;
mysql> start slave;

同样配置完成后,使用show slave status\G;语句查看主从同步状态,Slave_IO_RunningSlave_SQL_Running的值均为Yes才能表示主从同步状态是正常的:
基于MMM搭建MySQL Replication集群高可用架构


配置slave-01master-01的主从关系

接着就是配置从库对主库的主从关系了,这里与master-02是一样的,除非期间对master-01上的数据做了修改才需要重新获取日志点:

mysql> stop slave;
mysql> change master to master_host=‘192.168.190.146‘, master_port=3306, master_user=‘repl‘, master_password=‘Abc_123456‘, master_log_file=‘mysql_bin.000001‘, master_log_pos=155;
mysql> start slave;

搭建MMM服务

1、在所有的机器上安装 epel 源:

yum install -y epel-release

2、在所有的主从节点上安装MMM代理客户端:

yum install -y mysql-mmm-agent

3、在 manager节点上安装所有的MMM包:

yum install -y mysql-mmm*

4、然后在master-01上创建用于监控和代理的MySQL用户:

-- 监控用户
create user ‘mmm_monitor‘@‘%‘ identified with mysql_native_password by ‘Abc_123456‘;
grant replication client on *.* to ‘mmm_monitor‘@‘%‘;

-- 代理用户
create user ‘mmm_agent‘@‘%‘ identified with mysql_native_password by ‘Abc_123456‘;
grant super, replication client, process on *.* to ‘mmm_agent‘@‘%‘;
flush privileges;

由于配置了主从的原因,此时其他两个数据库节点也会同步这些新建的用户。在另外两个节点执行如下语句就可以查询到:

mysql> use mysql;
mysql> select host,user,plugin from user;
+-----------+------------------+-----------------------+
| host      | user             | plugin                |
+-----------+------------------+-----------------------+
| %         | mmm_agent        | mysql_native_password |
| %         | mmm_monitor      | mysql_native_password |
| %         | repl             | mysql_native_password |
| localhost | mysql.infoschema | caching_sha2_password |
| localhost | mysql.session    | caching_sha2_password |
| localhost | mysql.sys        | caching_sha2_password |
| localhost | root             | caching_sha2_password |
+-----------+------------------+-----------------------+

5、编辑所有节点包括监控节点上的mmm_common.conf配置文件,主要是配置当前节点和集群中其他节点的信息。这里以master-01节点为例,其配置内容如下:

[ ~]# vim /etc/mysql-mmm/mmm_common.conf
active_master_role      writer

<host default>
    cluster_interface       ens32  # 当前节点的网卡名称,用于绑定虚拟IP,可以ip addr命令查询
    pid_path                /run/mysql-mmm-agent.pid  # pid文件存放的路径
    bin_path                /usr/libexec/mysql-mmm/  # 可执行文件存放的路径
    replication_user        repl  # 用于复制的MySQL用户
    replication_password    Abc_123456  # repl用户的密码
    agent_user              mmm_agent   # 用于代理的MySQL用户
    agent_password          Abc_123456  # mmm_agent用户的密码
</host>

# 配置master-01的ip地址和角色
<host db1>
    ip      192.168.190.146
    mode    master
    peer    db2
</host>

# 配置master-02的ip地址和角色
<host db2>
    ip      192.168.190.148
    mode    master
    peer    db1
</host>

# 配置slave-01的ip地址和角色
<host db3>
    ip      192.168.190.149
    mode    slave
</host>

# 配置负责写操作的库
<role writer>
    hosts   db1, db2  # 指定可写的库,这里是上面host标签中定义的名称
    ips     192.168.190.90  # 配置写虚拟IP,可以有多个使用逗号分隔
    mode    exclusive   # 表示同一时刻只有一个主库提供服务
</role>

# 配置负责读操作的库
<role reader>
    hosts   db1, db2, db3  # 指定可读的库
    ips     192.168.190.91,192.168.190.92,192.168.190.93  # 配置读虚拟IP
    mode    balanced  # 表示将读请求负载均衡到以上所配置的db上
</role>

其他三个节点也按照相同的方式进行配置即可,除了网卡名称可能会不同外,其它的参数都应该是一致的。

6、然后配置各个节点的mmm_agent.conf文件,声明当前节点在host标签中所定义的名称。master-01节点的配置如下:

[ ~]# vim /etc/mysql-mmm/mmm_agent.conf
include mmm_common.conf
this db1

master-02节点的配置如下:

[ ~]# vim /etc/mysql-mmm/mmm_agent.conf
include mmm_common.conf
this db1

slave-01节点的配置如下:

[ ~]# vim /etc/mysql-mmm/mmm_agent.conf
include mmm_common.conf
this db3

7、接着配置监控节点上的mmm_mon.conf文件,配置内容如下:

[ ~]# vim /etc/mysql-mmm/mmm_mon.conf
include mmm_common.conf

<monitor>
    ip                  127.0.0.1
    pid_path            /run/mysql-mmm-monitor.pid
    bin_path            /usr/libexec/mysql-mmm
    status_path         /var/lib/mysql-mmm/mmm_mond.status
    ping_ips            192.168.190.146,192.168.190.148,192.168.190.149  # 配置集群中各个节点的IP
    auto_set_online     60  # 设置当节点宕机恢复后自动上线的时间,单位为秒

    # The kill_host_bin does not exist by default, though the monitor will
    # throw a warning about it missing.  See the section 5.10 "Kill Host
    # Functionality" in the PDF documentation.
    #
    # kill_host_bin     /usr/libexec/mysql-mmm/monitor/kill_host
    #
</monitor>

<host default>
    # 配置用于监控的MySQL用户和密码
    monitor_user        mmm_monitor
    monitor_password    Abc_123456
</host>

debug 0

8、启动所有主从节点的MMM代理服务:

[ ~]# systemctl start mysql-mmm-agent
[ ~]# systemctl start mysql-mmm-agent
[ ~]# systemctl start mysql-mmm-agent

agent服务默认会监听9989端口,如果开启了防火墙则需要开放该端口:

firewall-cmd --zone=public --add-port=9989/tcp --permanent
firewall-cmd --reload

9、启动监控节点上的监控服务:

[ ~]# systemctl start mysql-mmm-monitor

10、完成以上所有步骤后,在监控节点上使用mmm_control show命令就可以查看到集群中各个节点的状态及其分配的虚拟IP,如下示例:

[ ~]# mmm_control show
  db1(192.168.190.146) master/ONLINE. Roles: reader(192.168.190.91), writer(192.168.190.90)
  db2(192.168.190.148) master/ONLINE. Roles: reader(192.168.190.93)
  db3(192.168.190.149) slave/ONLINE. Roles: reader(192.168.190.92)

[ ~]#

测试

到此为止,我们就已经完成了MMM高可用架构的搭建,接下来我们对其进行一些简单的测试。例如,测试下是否能正常ping通虚拟IP,毕竟应用端访问数据库时连接的是虚拟IP,所以首先得确保虚拟IP是能够被访问的。如下:
基于MMM搭建MySQL Replication集群高可用架构

ping通之后,使用Navicat等远程连接工具测试下能否正常连接上:
基于MMM搭建MySQL Replication集群高可用架构

确定了各个虚拟IP都能正常访问后,测试下MMM是否能正常进行故障转移,首先将master-01上的MySQL服务给停掉:

[ ~]# systemctl stop mysqld

正常情况下,此时到监控节点上使用mmm_control show命令可以看到master-01节点已经处于脱机状态,而用于写的虚拟IP正常的切换到了master-02节点上:

[ ~]# mmm_control show
  db1(192.168.190.146) master/HARD_OFFLINE. Roles: 
  db2(192.168.190.148) master/ONLINE. Roles: reader(192.168.190.93), writer(192.168.190.90)
  db3(192.168.190.149) slave/ONLINE. Roles: reader(192.168.190.91), reader(192.168.190.92)

[ ~]#

接着进入slave-01节点上的MySQL终端。之前我们配置slave-01的主库是master-01,现在已经将master-01停掉后,可以看到slave-01的主库被MMM切换成了master-02
基于MMM搭建MySQL Replication集群高可用架构

经过以上测试后,可以看到我们搭建的MMM架构是能够正常运行的,已经使得Replication集群拥有了基本的高可用能力,即便主库下线后也能正常切换到备库上,也正确建立了从库与新主库的关系。


MMM架构的优缺点

优点:

  • 使用Perl脚本语言开发并且完全开源,开发者可以根据自己的需求进行二次开发
  • 提供了从服务器的延迟监控以及读写VIP(虚拟IP),使服务器角色的变更对前端应用透明。并且在从库出现大量的主从延迟或主从复制链路中断时,可以把这台从库上的读虚拟IP,漂移到集群中其他正常的可读节点上
  • 提供了当主库故障转移后,从库对新主库的重新同步功能,所以很容易对发生故障的主库重新上线,让Replication集群具备高可用性

缺点:

  • MMM属于一个比较老的工具了,其最后发布的版本也是好几年前了,所以会存在一些小bug,并且不支持MySQL 5.6+版本中新增的基于GTID的复制,只支持基于日志点的复制
  • 没有提供读负载均衡的功能,需要额外引入LVS等工具来实现
  • 在进行主从切换时,容易造成数据丢失或事务的重复提交。因为MMM不会对比多个从库的日志点,而是直接选择备库进行切换。由于Replication集群是异步复制的,当备库的同步延迟比较大时,可能会出现从库的日志点比备库的要更新。所以当主库意外下线时,MMM强制切换成备库就有可能会导致数据的丢失或从库重复提交事务
  • MMM没有提供相关的高可用功能,所以监控节点自身存在单点故障,而Replication集群的高可用依赖于监控节点,当监控节点挂掉Replication集群也就不再具备高可用性了。但我们可以引入第三方工具来对监控节点做双机热备,例如Keepalived

综合优缺点可以得知:MMM仅适用于对数据一致性要求不高,允许丢失少量数据的场景下,例如评论、资讯类等数据

相关推荐