基于MMM创建MySQL Replication集群高可用架
发布时间：2022-06-28 14:10:41 所属栏目：MySql教程 来源：互联网
导读：MMM介绍 MMM是Multi-Master Replication Manager for MySQL的缩写，它是MySQL提供的一个多主复制管理器，其核心是使用perl语言编写的一组脚本。实际上MMM是比较早期甚至有点老的一种用于构建高可用MySQL架构的方式，但因其还有一定的应用场景，所以本文将
|
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架构 以上述架构为例，描述一下故障转移的流程，现在假设 Master1 宕机： Monitor 检测到 Master1 连接失败 Monitor 发送 set_offline 指令到 Master1 的 Agent Master1 Agent 如果存活，下线写 VIP，尝试把 Master1 设置为 read_only=1 Moniotr 发送 set_online 指令到 Master2 Master2 Agent 接收到指令，执行 select master_pos_wait() 等待同步完毕 Master2 Agent 上线写 VIP，把 Master2 节点设为 read_only=0 Monitor 发送更改同步对象的指令到各个 Slave 节点的 Agent 各个 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用户（至少拥有super、replication client、process权限） 复制用户 1 用于配置MySQL主从复制的用户（至少拥有replication slave权限） 本文中所使用的机器说明： 名称 IP 角色 master-01 192.168.190.146 主库 master-02 192.168.190.148 备库 slave-01 192.168.190.149 从库 manager 192.168.190.147 集群管理器（MMM） 环境版本说明： 操作系统版本：CentOS 7 MySQL版本：8.0.19 MMM版本：2.2.1 另外的说明： 会来了解MMM架构的小伙伴们想必都已经掌握了MySQL的安装方式，而且介绍MySQL的安装也有很多文章，所以本文为了减少不必要的篇幅就不演示MySQL的安装了，文中所用到的机器都已经提前安装好了MySQL。 配置主主复制及主从同步集群 1、在master-01和master-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配置文件： [root@master-01 ~]# 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不一样： [root@master-02 ~]# 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参数： [root@slave-01 ~]# vim /etc/my.cnf [mysqld] server_id=103 log_bin=mysql_bin relay_log=relay_bin 完成以上配置文件的修改后，分别重启这三个节点上的MySQL服务： [root@master-01 ~]# systemctl restart mysqld [root@master-02 ~]# systemctl restart mysqld [root@slave-01 ~]# systemctl restart mysqld 配置master-02对master-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 | | | | +------------------+----------+--------------+------------------+-------------------+ 记录其中的File和Position的值，然后进入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 statusG;语句查看主从同步状态，Slave_IO_Running和Slave_SQL_Running的值均为Yes才能表示主从同步状态是正常的： 配置master-01对master-02的主从关系 为了实现主主复制，master-01和master-02需要互为主从关系，所以还需要配置master-01对master-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 | | | | +------------------+----------+--------------+------------------+-------------------+ 记录其中的File和Position的值，然后进入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 statusG;语句查看主从同步状态，Slave_IO_Running和Slave_SQL_Running的值均为Yes才能表示主从同步状态是正常的： 基于MMM搭建MySQL Replication集群高可用架 配置slave-01对master-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节点为例，其配置内容如下： [root@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节点的配置如下： [root@master-01 ~]# vim /etc/mysql-mmm/mmm_agent.conf include mmm_common.conf this db1 master-02节点的配置如下： [root@master-02 ~]# vim /etc/mysql-mmm/mmm_agent.conf include mmm_common.conf this db1 slave-01节点的配置如下： [root@slave-01 ~]# vim /etc/mysql-mmm/mmm_agent.conf include mmm_common.conf this db3 7、接着配置监控节点上的mmm_mon.conf文件，配置内容如下： [root@manager ~]# 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代理服务： [root@master-01 ~]# systemctl start mysql-mmm-agent [root@master-02 ~]# systemctl start mysql-mmm-agent [root@slave-01 ~]# systemctl start mysql-mmm-agent agent服务默认会监听9989端口，如果开启了防火墙则需要开放该端口： firewall-cmd --zone=public --add-port=9989/tcp --permanent firewall-cmd --reload 9、启动监控节点上的监控服务： [root@manager ~]# systemctl start mysql-mmm-monitor 10、完成以上所有步骤后，在监控节点上使用mmm_control show命令就可以查看到集群中各个节点的状态及其分配的虚拟IP，如下示例： [root@manager ~]# 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) [root@manager ~]# 测试 到此为止，我们就已经完成了MMM高可用架构的搭建，接下来我们对其进行一些简单的测试。例如，测试下是否能正常ping通虚拟IP，毕竟应用端访问数据库时连接的是虚拟IP，所以首先得确保虚拟IP是能够被访问的。 确定了各个虚拟IP都能正常访问后，测试下MMM是否能正常进行故障转移，首先将master-01上的MySQL服务给停掉： [root@master-01 ~]# systemctl stop mysqld 正常情况下，此时到监控节点上使用mmm_control show命令可以看到master-01节点已经处于脱机状态，而用于写的虚拟IP正常的切换到了master-02节点上： [root@manager ~]# 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) [root@manager ~]# 接着进入slave-01节点上的MySQL终端。之前我们配置slave-01的主库是master-01，现在已经将master-01停掉后，可以看到slave-01的主库被MMM切换成了master-02： 经过以上测试后，可以看到我们搭建的MMM架构是能够正常运行的，已经使得Replication集群拥有了基本的高可用能力，即便主库下线后也能正常切换到备库上，也正确建立了从库与新主库的关系。 MMM架构的优缺点 优点： 使用Perl脚本语言开发并且完全开源，开发者可以根据自己的需求进行二次开发 提供了从服务器的延迟监控以及读写VIP（虚拟IP），使服务器角色的变更对前端应用透明。并且在从库出现大量的主从延迟或主从复制链路中断时，可以把这台从库上的读虚拟IP，漂移到集群中其他正常的可读节点上 提供了当主库故障转移后，从库对新主库的重新同步功能，所以很容易对发生故障的主库重新上线，让Replication集群具备高可用性 缺点： MMM属于一个比较老的工具了，其最后发布的版本也是好几年前了，所以会存在一些小bug，并且不支持MySQL 5.6+版本中新增的基于GTID的复制，只支持基于日志点的复制 没有提供读负载均衡的功能，需要额外引入LVS等工具来实现 在进行主从切换时，容易造成数据丢失或事务的重复提交。因为MMM不会对比多个从库的日志点，而是直接选择备库进行切换。由于Replication集群是异步复制的，当备库的同步延迟比较大时，可能会出现从库的日志点比备库的要更新。所以当主库意外下线时，MMM强制切换成备库就有可能会导致数据的丢失或从库重复提交事务 MMM没有提供相关的高可用功能，所以监控节点自身存在单点故障，而Replication集群的高可用依赖于监控节点，当监控节点挂掉Replication集群也就不再具备高可用性了。但我们可以引入第三方工具来对监控节点做双机热备，例如Keepalived 综合优缺点可以得知：MMM仅适用于对数据一致性要求不高，允许丢失少量数据的场景下。 （编辑：昌吉站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐