MySQL MGR高可用集群搭建与运维实战指南

1. MySQL MGR 高可用集群概述

MySQL Group Replication（简称MGR）是MySQL官方在5.7.17版本推出的高可用解决方案。作为一名数据库管理员，我在生产环境中使用MGR已有三年多时间，今天就来详细分享这套集群的搭建与运维经验。

MGR本质上是一个基于Paxos协议的分布式状态机复制系统。与传统的异步复制或半同步复制不同，MGR采用多主架构设计，通过组通信协议实现事务的原子广播。当客户端发起一个事务时，主节点会将该事务广播给组内所有成员，只有在大多数节点确认接收后，事务才会提交。这种设计保证了数据在集群中的强一致性。

2. 环境准备与规划

2.1 硬件配置建议

在生产环境中，我建议至少使用3台服务器组成MGR集群。以下是推荐的硬件配置：

• CPU：4核以上，MySQL对多核利用良好
• 内存：16GB起步，对于大型数据库建议32GB+
• 存储：SSD硬盘，容量根据数据量决定
• 网络：千兆内网互联，确保低延迟

重要提示：所有节点的MySQL版本必须完全一致，否则可能出现兼容性问题

2.2 网络配置

在/etc/hosts文件中添加所有节点的IP和主机名映射：

bash复制# 所有节点执行
cat >> /etc/hosts <<EOF
192.168.1.101 mgr-node1
192.168.1.102 mgr-node2
192.168.1.103 mgr-node3
EOF

2.3 防火墙设置

开放必要的端口：

bash复制firewall-cmd --permanent --add-port=3306/tcp
firewall-cmd --permanent --add-port=24901/tcp
firewall-cmd --reload

3. MySQL安装与配置

3.1 安装MySQL 8.0

bash复制# 添加MySQL YUM源
rpm -Uvh https://repo.mysql.com/mysql80-community-release-el7-5.noarch.rpm

# 安装MySQL Server
yum install -y mysql-community-server

3.2 配置MGR参数

以下是主节点的配置文件示例（/etc/my.cnf）：

ini复制[mysqld]
# 基本配置
server_id=1
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock

# 复制配置
log_bin=mysql-bin
binlog_format=ROW
binlog_checksum=NONE
gtid_mode=ON
enforce_gtid_consistency=ON

# MGR配置
plugin_load_add='group_replication.so'
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
group_replication_start_on_boot=OFF
group_replication_local_address="mgr-node1:24901"
group_replication_group_seeds="mgr-node1:24901,mgr-node2:24901,mgr-node3:24901"
group_replication_bootstrap_group=OFF

4. MGR集群初始化

4.1 启动第一个节点

sql复制-- 启动组复制引导
SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;

-- 验证状态
SELECT * FROM performance_schema.replication_group_members;

4.2 加入其他节点

在其他节点上执行：

sql复制-- 设置恢复通道
CHANGE MASTER TO MASTER_USER='repl_user', MASTER_PASSWORD='password' 
FOR CHANNEL 'group_replication_recovery';

-- 启动组复制
START GROUP_REPLICATION;

5. 运维与监控

5.1 常用监控命令

sql复制-- 查看组成员状态
SELECT * FROM performance_schema.replication_group_members;

-- 查看组复制通道状态
SHOW STATUS LIKE 'group_replication%';

-- 查看延迟情况
SELECT * FROM sys.gr_member_routing_candidate_status;

5.2 故障处理

当节点故障时，MGR会自动进行故障转移。手动恢复节点步骤：

1. 检查故障原因并修复
2. 启动MySQL服务
3. 重新加入组复制：

   sql复制START GROUP_REPLICATION;
   

6. 性能优化建议

1. 事务大小控制：单个事务建议不超过100MB
2. 网络优化：确保节点间网络延迟<1ms
3. 参数调整：

   ini复制group_replication_flow_control_mode="QUOTA"
   group_replication_flow_control_applier_threshold=25000
   group_replication_flow_control_certifier_threshold=25000
   

7. 生产环境经验分享

在实际使用中，我总结了以下几点经验：

1. 监控必不可少：建议部署Prometheus+Granfa监控MGR状态
2. 定期备份：即使有MGR也要做物理备份
3. 版本升级：先在从节点升级测试，再升级主节点
4. 避免大事务：大事务会导致整个组阻塞

8. 单主与多主模式选择

8.1 单主模式特点

• 自动故障转移
• 读写分离
• 适合大多数业务场景

8.2 多主模式特点

• 所有节点可写
• 需要处理冲突
• 适合特定业务场景

模式切换命令：

sql复制-- 切换到多主模式
SET GLOBAL group_replication_single_primary_mode=OFF;
SET GLOBAL group_replication_enforce_update_everywhere_checks=ON;

9. 常见问题解决方案

9.1 节点无法加入集群

可能原因：

1. 防火墙未开放24901端口
2. 节点间时间不同步
3. 配置文件中server_id重复

9.2 复制延迟大

解决方法：

1. 检查网络状况
2. 优化大事务
3. 调整flow control参数

10. 总结

MySQL MGR作为官方提供的高可用解决方案，在保证数据一致性的同时提供了自动故障转移能力。经过三年多的生产环境验证，我认为它特别适合以下场景：

1. 金融级数据一致性要求
2. 需要自动故障转移的环境
3. 读多写少的业务场景

在实际部署时，建议从测试环境开始，充分验证后再上线生产。同时要做好监控和备份，确保万无一失。