1. MySQL集群架构选型困境在数据库高可用方案的选择上许多DBA团队都面临过这样的纠结是选择传统的MySQL主备架构还是尝试较新的MGRMySQL Group Replication方案去年我们电商平台数据库升级时就曾对这两种架构进行了长达三个月的对比测试。主备架构作为MySQL最经典的高可用方案通过binlog复制实现数据同步其稳定性经过十多年验证。而MGR作为MySQL 5.7版本引入的官方集群方案基于Paxos协议实现多主写入理论上能提供更高的可用性。但实际选型时需要考虑的因素远不止这些。2. 核心机制对比2.1 数据同步原理主备集群采用异步或半同步复制异步复制主库执行事务后立即响应客户端binlog异步传输到备库半同步复制至少一个备库接收binlog后主库才提交事务# 半同步复制配置示例 INSTALL PLUGIN rpl_semi_sync_master SONAME semisync_master.so; SET GLOBAL rpl_semi_sync_master_enabled 1;MGR使用组复制技术基于Paxos协议实现多节点原子广播事务在本地执行后需要得到多数节点认证默认使用流控机制避免网络分区关键区别MGR的认证过程是同步的而传统主备复制中备库应用日志是异步的2.2 故障处理机制主备集群的典型故障转移流程检测主库不可用通常通过VIP心跳选择数据最接近的备库提升为新主其他备库重新指向新主应用连接切换到新主MGR的故障检测节点间互相监控5秒心跳超时自动剔除故障节点剩余节点自动重组集群# 查看MGR成员状态 SELECT * FROM performance_schema.replication_group_members;3. 性能实测对比我们在相同硬件环境16C32G SSD下进行了基准测试测试项主备集群(QPS)MGR集群(QPS)纯读负载58,00055,000纯写负载12,0009,800混合读写(7:3)23,00018,000网络延迟50ms时19,0006,500出现性能差异的主要原因MGR需要多数节点确认事务认证过程消耗额外CPU资源网络延迟对MGR影响更大4. 运维复杂度分析4.1 部署配置主备集群部署步骤初始化各节点my.cnf建立复制账号配置主从关系# 传统主从搭建命令 CHANGE MASTER TO MASTER_HOSTmaster_host, MASTER_USERrepl, MASTER_PASSWORDpassword;MGR集群部署额外要求需要配置group_replication插件必须启用GTID需要配置集群引导参数# MGR必须配置项 plugin_load_addgroup_replication.so group_replication_start_on_bootOFF group_replication_group_nameaaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa4.2 日常运维主备集群常见问题复制延迟累积主备数据不一致脑裂风险MGR特有运维场景多数节点宕机导致集群不可用流控机制导致性能波动新节点加入需要数据全量同步5. 生产环境选型建议经过实测我们总结出以下选型原则适合MGR的场景需要多写能力的业务网络质量稳定的内网环境对自动故障转移要求高的系统能够接受10-20%性能损耗适合主备集群的场景读写分离架构跨机房部署对写入性能要求苛刻已有成熟的监控运维体系特殊注意事项MGR对MySQL版本要求严格各节点必须版本一致云环境部署MGR需要注意安全组规则大事务在MGR中更容易引发流控6. 混合架构实践案例我们在核心交易系统采用了折中方案写节点主备集群保证写入性能读节点MGR集群3节点提供高可用通过ProxySQL实现读写分离这种架构在双11期间的表现写入峰值QPS 15,000读取峰值QPS 85,000主库故障转移时间15秒配置示例-- ProxySQL路由规则 INSERT INTO mysql_servers(hostgroup_id,hostname,port) VALUES (10,master-host,3306), (20,mgr-node1,3306), (20,mgr-node2,3306), (20,mgr-node3,3306); INSERT INTO mysql_query_rules (rule_id,active,match_pattern,destination_hostgroup,apply) VALUES (1,1,^SELECT.*FOR UPDATE,10,1), (2,1,^SELECT,20,1);7. 故障恢复实战记录去年我们遇到一次典型MGR故障现象集群突然不可写但所有节点服务正常排查SHOW STATUS LIKE group_replication%; -- 发现group_replication_primary_member状态为空原因网络抖动导致节点失去多数派解决# 在少数派节点上强制重置集群 SET GLOBAL group_replication_force_members192.168.1.101:33061;后续优化调整group_replication_member_expel_timeout增加物理心跳线部署延迟备节点这个案例让我深刻理解到MGR的自动容灾能力是把双刃剑配置不当反而会增加运维复杂度。 
长河君 · 2026/10/29 15:44:33 · 阅读 1.2k MySQL高可用方案对比：主备架构与MGR技术解析
1. MySQL集群架构选型困境在数据库高可用方案的选择上许多DBA团队都面临过这样的纠结是选择传统的MySQL主备架构还是尝试较新的MGRMySQL Group Replication方案去年我们电商平台数据库升级时就曾对这两种架构进行了长达三个月的对比测试。主备架构作为MySQL最经典的高可用方案通过binlog复制实现数据同步其稳定性经过十多年验证。而MGR作为MySQL 5.7版本引入的官方集群方案基于Paxos协议实现多主写入理论上能提供更高的可用性。但实际选型时需要考虑的因素远不止这些。2. 核心机制对比2.1 数据同步原理主备集群采用异步或半同步复制异步复制主库执行事务后立即响应客户端binlog异步传输到备库半同步复制至少一个备库接收binlog后主库才提交事务# 半同步复制配置示例 INSTALL PLUGIN rpl_semi_sync_master SONAME semisync_master.so; SET GLOBAL rpl_semi_sync_master_enabled 1;MGR使用组复制技术基于Paxos协议实现多节点原子广播事务在本地执行后需要得到多数节点认证默认使用流控机制避免网络分区关键区别MGR的认证过程是同步的而传统主备复制中备库应用日志是异步的2.2 故障处理机制主备集群的典型故障转移流程检测主库不可用通常通过VIP心跳选择数据最接近的备库提升为新主其他备库重新指向新主应用连接切换到新主MGR的故障检测节点间互相监控5秒心跳超时自动剔除故障节点剩余节点自动重组集群# 查看MGR成员状态 SELECT * FROM performance_schema.replication_group_members;3. 性能实测对比我们在相同硬件环境16C32G SSD下进行了基准测试测试项主备集群(QPS)MGR集群(QPS)纯读负载58,00055,000纯写负载12,0009,800混合读写(7:3)23,00018,000网络延迟50ms时19,0006,500出现性能差异的主要原因MGR需要多数节点确认事务认证过程消耗额外CPU资源网络延迟对MGR影响更大4. 运维复杂度分析4.1 部署配置主备集群部署步骤初始化各节点my.cnf建立复制账号配置主从关系# 传统主从搭建命令 CHANGE MASTER TO MASTER_HOSTmaster_host, MASTER_USERrepl, MASTER_PASSWORDpassword;MGR集群部署额外要求需要配置group_replication插件必须启用GTID需要配置集群引导参数# MGR必须配置项 plugin_load_addgroup_replication.so group_replication_start_on_bootOFF group_replication_group_nameaaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa4.2 日常运维主备集群常见问题复制延迟累积主备数据不一致脑裂风险MGR特有运维场景多数节点宕机导致集群不可用流控机制导致性能波动新节点加入需要数据全量同步5. 生产环境选型建议经过实测我们总结出以下选型原则适合MGR的场景需要多写能力的业务网络质量稳定的内网环境对自动故障转移要求高的系统能够接受10-20%性能损耗适合主备集群的场景读写分离架构跨机房部署对写入性能要求苛刻已有成熟的监控运维体系特殊注意事项MGR对MySQL版本要求严格各节点必须版本一致云环境部署MGR需要注意安全组规则大事务在MGR中更容易引发流控6. 混合架构实践案例我们在核心交易系统采用了折中方案写节点主备集群保证写入性能读节点MGR集群3节点提供高可用通过ProxySQL实现读写分离这种架构在双11期间的表现写入峰值QPS 15,000读取峰值QPS 85,000主库故障转移时间15秒配置示例-- ProxySQL路由规则 INSERT INTO mysql_servers(hostgroup_id,hostname,port) VALUES (10,master-host,3306), (20,mgr-node1,3306), (20,mgr-node2,3306), (20,mgr-node3,3306); INSERT INTO mysql_query_rules (rule_id,active,match_pattern,destination_hostgroup,apply) VALUES (1,1,^SELECT.*FOR UPDATE,10,1), (2,1,^SELECT,20,1);7. 故障恢复实战记录去年我们遇到一次典型MGR故障现象集群突然不可写但所有节点服务正常排查SHOW STATUS LIKE group_replication%; -- 发现group_replication_primary_member状态为空原因网络抖动导致节点失去多数派解决# 在少数派节点上强制重置集群 SET GLOBAL group_replication_force_members192.168.1.101:33061;后续优化调整group_replication_member_expel_timeout增加物理心跳线部署延迟备节点这个案例让我深刻理解到MGR的自动容灾能力是把双刃剑配置不当反而会增加运维复杂度。