在前面的文章中我们介绍了传统的主从复制与 GTID 复制。虽然 GTID 解决了位点管理的难题但在故障切换时仍需人工介入或依赖第三方工具。今天我们将介绍 MySQL 官方推出的高可用方案——MySQL Group Replication (MGR)。它基于 Paxos 协议实现了分布式环境下的数据一致性并提供自动故障检测与主节点选举能力是构建现代 MySQL 高可用架构的首选。一、 MGR 核心原理简述与传统主从复制不同MGR 不再依赖 IO 线程单向拉取 binlog而是通过Paxos 协议在组成员之间实现事务的原子广播。冲突检测每个事务凭借全局唯一的 GTID 和写集合在多节点间完成冲突判定保证集群内数据最终一致。单主模式本实验采用单主模式主节点负责写入备节点处理读请求。备节点加入集群后默认自动进入super_read_only只读模式。关键配置MGR 强制要求开启二进制日志ROW 格式、GTID并配置好通信地址。二、 环境准备本次实战采用三节点集群信息如下角色IP 地址主机名server-id主节点192.168.146.173mgr11备节点1192.168.146.176mgr22备节点2192.168.146.177mgr33前置条件三台节点互信配置好主机名解析 (/etc/hosts)。关闭防火墙和 SELinux防止通信端口被拦截。确保 MySQL 版本一致建议 8.0。三、 配置文件修改MGR 对配置文件要求较高所有节点均需修改/etc/my.cnf。请务必注意各节点server-id和group_replication_local_address的唯一性。以下以备节点 177 (mgr3)为例其他节点请修改对应 IP 和 server-idcat /etc/my.cnf EOF [mysqld] usermysql basedir/usr/local/mysql datadir/data/mysql socket/tmp/mysql.sock port3306 pid-file/data/mysql/mysql.pid log-error/data/mysql/mysql.err # 1. 唯一性配置 server-id3 # 2. MGR 核心 Binlog 配置 (必须为 ROW 格式) log-bin/data/mysql/mysql-bin binlog_formatROW binlog_row_imageFULL # 3. GTID 配置 gtid_modeON enforce_gtid_consistencyON log_replica_updatesON # 4. 认证插件 (避开 8.0 SSL 握手问题) default_authentication_pluginmysql_native_password # 5. MGR 插件配置 plugin_dir/usr/local/mysql/lib/plugin # 组名 (UUID格式)所有节点必须一致 loose-group_replication_group_nameaaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee # 本机通信地址必须修改为本机 IP loose-group_replication_local_address192.168.146.177:33061 # 种子节点列表列出集群所有节点 loose-group_replication_group_seeds192.168.146.173:33061,192.168.146.176:33061,192.168.146.177:33061 # 禁止引导和开机自启 (防止误操作) loose-group_replication_bootstrap_groupOFF loose-group_replication_start_on_bootOFF # 关闭 SSL 简化配置 loose-group_replication_ssl_modeDISABLED loose-group_replication_recovery_use_native_passwordON EOF避坑指南binlog_row_image必须设为FULL否则无法提取写集合进行冲突检测。server-id和auto.cnf中的 UUID 必须全集群唯一。配置修改完成后请执行systemctl restart mysqld重启所有节点。四、 集群初始化操作以下 SQL 操作需要在所有节点3 台上全部执行。1. 安装 MGR 插件INSTALL PLUGIN group_replication SONAME group_replication.so;2. 创建同步账号为了防止 MySQL 8.0 报错 “Cannot store the user in the replication metadata”, 必须给复制用户设置密码且建议暂时禁止日志记录防止复制账号同步到其他节点。-- 暂时禁止日志记录 SET SQL_LOG_BIN0; -- 创建用户并指定认证方式 CREATE USER rpl_user% IDENTIFIED WITH mysql_native_password BY Replica123; GRANT REPLICATION SLAVE ON *.* TO rpl_user%; GRANT BACKUP_ADMIN ON *.* TO rpl_user%; FLUSH PRIVILEGES; -- 恢复日志记录 SET SQL_LOG_BIN1;3. 配置恢复通道配置用于分布式恢复的复制通道。CHANGE REPLICATION SOURCE TO SOURCE_USERrpl_user, SOURCE_PASSWORDReplica123 FOR CHANNEL group_replication_recovery;五、 启动 MGR 集群 (严格按顺序)启动过程分为引导启动和加入集群两个步骤必须严格按顺序执行。第一步主节点 引导启动仅在主节点 (192.168.146.173) 执行-- 开启引导标志 SET GLOBAL group_replication_bootstrap_groupON; -- 启动组复制 START GROUP_REPLICATION; -- 关闭引导标志 (重要启动后必须立即关闭) SET GLOBAL group_replication_bootstrap_groupOFF; -- 检查状态预期MEMBER_STATEONLINE, MEMBER_ROLEPRIMARY SELECT MEMBER_HOST, MEMBER_PORT, MEMBER_STATE, MEMBER_ROLE FROM performance_schema.replication_group_members;第二步备节点 1 (176) 加入集群仅在备节点 1 执行-- 直接启动即可加入 START GROUP_REPLICATION; -- 检查状态预期该节点变为 ONLINE 和 SECONDARY SELECT MEMBER_HOST, MEMBER_PORT, MEMBER_STATE, MEMBER_ROLE FROM performance_schema.replication_group_members;第三步备节点 2 (177) 加入集群仅在备节点 2 执行-- 直接启动 START GROUP_REPLICATION; -- 检查状态预期3 个节点全部为 ONLINE SELECT MEMBER_HOST, MEMBER_PORT, MEMBER_STATE, MEMBER_ROLE FROM performance_schema.replication_group_members;六、 常见问题排查搭建 MGR 集群时如果节点状态一直处于RECOVERING或无法变为ONLINE请重点排查以下原因端口未放行MGR 除了 MySQL 服务端口 (3306)还需要通信端口 (默认为 33061)。请确保防火墙放行该端口。认证失败检查recovery通道的用户名密码是否正确是否使用了mysql_native_password。配置冲突确认所有节点的server-id是否唯一group_replication_group_name是否一致。只读模式MGR 启动后备节点会自动开启super_read_only。如果需要在备节点执行管理操作如安装插件需先手动执行SET GLOBAL super_read_only0;操作完毕后记得恢复只读。通过 MGR 集群我们实现了 MySQL 的自动故障检测与高可用切换极大提升了系统的稳定性。希望这份实战指南能帮助您顺利完成架构升级
)
