MySQL 8.0 高可用架构实战：基于MGR构建3节点集群与故障切换演练

1. 生产环境高可用架构设计原则

在构建MySQL高可用架构时，我们需要遵循几个核心原则。首先是 服务连续性 ，确保数据库在硬件故障、网络分区等异常情况下仍能提供服务。其次是 数据一致性 ，这是分布式系统设计的核心挑战。最后是 运维便捷性 ，任何复杂的架构如果难以维护都会成为技术债务。

MySQL Group Replication（MGR）作为MySQL 8.0原生提供的高可用解决方案，完美平衡了这三个原则。它基于Paxos协议实现多节点数据同步，具备以下特性：

• 自动故障检测与恢复 ：节点故障时自动触发主从切换
• 多主模式支持 ：所有节点均可处理写请求（需应用层适配）
• 数据强一致性 ：确保事务在所有节点要么全部提交要么全部回滚

以下是传统主从复制与MGR的对比：

特性	传统主从复制	MGR
故障切换时间	分钟级	秒级
数据一致性	最终一致	即时一致
写节点扩展性	单点写入	多点写入（可选）
拓扑管理	手动配置	自动管理

2. 三节点MGR集群搭建实战

2.1 环境准备

建议使用相同规格的服务器，以下是推荐配置：

# 系统要求
CPU: 8核以上
内存: 32GB以上
磁盘: SSD/NVMe，建议RAID10
网络: 万兆互联，延迟<1ms

每个节点需要安装MySQL 8.0.26+版本，配置前确保：

1. 主机名解析正确（/etc/hosts或DNS）
2. 防火墙开放3306和组通信端口（建议24000-24999）
3. 时间同步服务（NTP/Chrony）正常运行

2.2 关键参数配置

修改my.cnf配置文件，以下为最小化MGR配置：

[mysqld]
# 基础配置
server_id = 1  # 每个节点唯一
gtid_mode = ON
enforce_gtid_consistency = ON
binlog_format = ROW
binlog_checksum = NONE
log_slave_updates = ON
log_bin = mysql-bin
binlog_group_commit_sync_delay = 100
binlog_group_commit_sync_no_delay_count = 10

# MGR专用配置
plugin_load_add = 'group_replication.so'
transaction_write_set_extraction = XXHASH64
loose-group_replication_group_name = "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"  # 集群UUID
loose-group_replication_start_on_boot = OFF
loose-group_replication_local_address = "node1:33061"  # 各节点修改为实际地址
loose-group_replication_group_seeds = "node1:33061,node2:33061,node3:33061"
loose-group_replication_bootstrap_group = OFF
loose-group_replication_single_primary_mode = ON  # 单主模式
loose-group_replication_consistency = BEFORE_ON_PRIMARY_FAILOVER

注意：生产环境建议将 loose-group_replication_consistency 设置为 AFTER 以获得更好的性能表现

2.3 集群初始化流程

在第一个节点执行引导操作：

-- 创建复制专用账户
SET SQL_LOG_BIN=0;
CREATE USER repl@'%' IDENTIFIED BY 'SecurePass123!';
GRANT REPLICATION SLAVE ON *.* TO repl@'%';
GRANT BACKUP_ADMIN ON *.* TO repl@'%';
SET SQL_LOG_BIN=1;

-- 配置group_replication_recovery通道
CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='SecurePass123!'
  FOR CHANNEL 'group_replication_recovery';

-- 启动组复制（引导模式）
SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;

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

其他节点加入集群：

-- 配置recovery通道（同引导节点）
-- 直接启动组复制
START GROUP_REPLICATION USER='repl', PASSWORD='SecurePass123!';

3. 故障切换场景测试

3.1 主节点宕机测试

模拟主节点故障的最简单方法是直接kill MySQL进程：

# 在主节点执行
sudo systemctl stop mysql

在剩余节点上观察故障转移：

-- 查看集群成员状态
SELECT 
  member_id,
  member_host,
  member_port,
  member_state,
  member_role 
FROM performance_schema.replication_group_members;

-- 查看新主节点选举情况
SHOW STATUS LIKE 'group_replication_primary_member';

典型故障转移时间轴：

1. 故障检测（5-10秒）：组成员通过心跳检测到主节点不可达
2. 新主选举（1-2秒）：剩余节点基于server_uuid进行选举
3. 流量切换（即时）：应用应通过读写分离中间件自动重连

3.2 网络分区处理

网络分区是高可用系统最棘手的场景。MGR通过 group_replication_unreachable_majority_timeout 参数（默认120秒）控制：

-- 模拟网络分区（在受影响节点执行）
SET GLOBAL group_replication_unreachable_majority_timeout=30;  # 缩短超时

-- 恢复后重新加入集群
START GROUP_REPLICATION USER='repl', PASSWORD='SecurePass123!';

网络分区处理策略建议：

• 奇数节点部署（3/5/7节点）
• 跨可用区部署时配置合理的超时时间
• 监控 group_replication_communication_disconnected 状态

4. 生产环境优化建议

4.1 性能调优参数

# 组通信优化
group_replication_flow_control_mode = "QUOTA"
group_replication_flow_control_applier_threshold = 25000
group_replication_flow_control_certifier_threshold = 25000

# 并行应用设置
slave_parallel_workers = 16
slave_parallel_type = LOGICAL_CLOCK
binlog_transaction_dependency_tracking = WRITESET

4.2 监控指标清单

关键监控项及阈值建议：

指标名称	警告阈值	严重阈值
Group replication member status	-	OFFLINE
Replication lag (seconds)	5	30
Flow control paused (ms/min)	1000	5000
Certification queue size	10000	50000
Conflicts detected	1	10

4.3 备份恢复策略

即使使用MGR也需要定期备份，推荐Percona XtraBackup与MGR配合：

# 备份命令示例
xtrabackup --backup --slave-info --target-dir=/backups/$(date +%F) \
  --user=backup --password=BackupPass123!
   
# 从备份创建新节点
xtrabackup --prepare --target-dir=/backups/2023-06-15
rsync -avzP /backups/2023-06-15/ newnode:/var/lib/mysql/

5. 异常场景处理手册

5.1 脑裂处理流程

当出现双主情况时：

1. 确认网络连通性
2. 选择数据较新的节点作为幸存者
3. 在另一个节点执行：

STOP GROUP_REPLICATION;
SET GLOBAL group_replication_allow_local_disjoint_gtids_join=ON;
START GROUP_REPLICATION;

5.2 节点自动驱逐问题

常见原因及解决方案：

• 认证失败 ：检查 group_replication_gtid_assignment_block_size 设置
• 事务过大 ：调整 group_replication_transaction_size_limit （默认143MB）
• 磁盘满 ：监控 disk_free_space 指标

5.3 版本升级策略

滚动升级步骤：

1. 从最后一个从节点开始升级
2. 逐个重启节点验证兼容性
3. 最后升级主节点（需先切换）
4. 建议先在测试环境验证版本兼容性

-- 安全切换主节点
SELECT group_replication_set_as_primary('node2-uuid');