MySQL高可用架构入门：从主从切换到MGR集群指南

MySQL高可用架构入门从主从切换到MGR集群指南本文涵盖架构选型、MGR搭建、故障切换等核心环节可直接用于生产环境参考。一、高可用架构选型找到适合你的方案在动手之前先理清主流方案的适用场景架构方案数据一致性自动故障转移复杂度适用场景异步主从复制弱可能丢数据需配合MHA/ Orchestrator低读多写少、容忍秒级延迟半同步复制较强需配合MHA中金融级读分离MGR组复制强多数派确认原生支持中核心交易系统、强一致要求InnoDB Cluster强原生支持中中小规模完整高可用方案MHA 半同步较强成熟方案中高传统互联网架构选型建议新项目首选MGRMySQL 5.7.17/8.0原生支持省去MHA等外部组件依赖存量系统改造可考虑MHA 半同步过渡云环境直接使用RDS高可用版自建机房用MGR二、MGR集群基础搭建三节点单主模式MGRMySQL Group Replication是MySQL官方推出的组复制技术基于Paxos协议实现数据强一致。2.1 环境准备假设三台服务器node1: 192.168.1.101主节点node2: 192.168.1.102node3: 192.168.1.103所有节点执行# 关闭防火墙或开放端口systemctl stop firewalld# 或开放3306和组通信端口firewall-cmd --add-port3306/tcp--permanentfirewall-cmd --add-port33061/tcp--permanent# 组通信端口firewall-cmd--reload# 确保时间同步yuminstall-ychrony systemctlenablechronydsystemctl start chronyd2.2 MySQL配置文件my.cnf关键配置项所有节点server_id需不同[mysqld] # 基础配置 server_id101 # node2改为102node3改为103 datadir/var/lib/mysql socket/var/lib/mysql/mysql.sock # GTID配置MGR强制要求 gtid_modeON enforce_gtid_consistencyON binlog_gtid_simple_recoveryON # 组复制配置 plugin_load_addgroup_replication.so transaction_write_set_extractionXXHASH64 # 事务写集提取 binlog_checksumNONE # MGR不支持binlog checksum # 组复制参数 loose-group_replication_group_nameaaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee # UUID格式 loose-group_replication_start_on_bootOFF loose-group_replication_local_address192.168.1.101:33061 # 各节点修改IP loose-group_replication_group_seeds192.168.1.101:33061,192.168.1.102:33061,192.168.1.103:33061 loose-group_replication_bootstrap_groupOFF # 单主模式推荐生产使用 loose-group_replication_single_primary_modeON loose-group_replication_enforce_update_everywhere_checksOFF # 性能优化 slave_parallel_typeLOGICAL_CLOCK slave_parallel_workers42.3 初始化集群node1执行-- 创建复制用户CREATEUSERrepl%IDENTIFIEDBYStrongPassword123!;GRANTREPLICATIONSLAVEON*.*TOrepl%;FLUSHPRIVILEGES;-- 配置组复制通道CHANGE MASTERTOMASTER_USERrepl,MASTER_PASSWORDStrongPassword123!FORCHANNELgroup_replication_recovery;-- 安装组复制插件如未自动加载INSTALL PLUGIN group_replicationSONAMEgroup_replication.so;-- 启动第一个节点引导组SETGLOBALgroup_replication_bootstrap_groupON;STARTGROUP_REPLICATION;SETGLOBALgroup_replication_bootstrap_groupOFF;-- 验证状态SELECT*FROMperformance_schema.replication_group_members;预期输出-------------------------------------------------------------------------------------- | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | -------------------------------------------------------------------------------------- | group_replication_applier | xxxxxxxx | node1 | 3306 | ONLINE | --------------------------------------------------------------------------------------2.4 加入其他节点node2/node3执行-- 同样创建复制用户或从node1同步数据后CREATEUSERrepl%IDENTIFIEDBYStrongPassword123!;GRANTREPLICATIONSLAVEON*.*TOrepl%;FLUSHPRIVILEGES;CHANGE MASTERTOMASTER_USERrepl,MASTER_PASSWORDStrongPassword123!FORCHANNELgroup_replication_recovery;-- 直接启动组复制自动加入现有组STARTGROUP_REPLICATION;验证集群状态-- 查看所有成员SELECTMEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLEFROMperformance_schema.replication_group_members;-- 查看主节点SHOWSTATUSLIKEgroup_replication_primary_member;三、故障自动切换机制MGR单主模式下故障切换是自动的无需MHA等外部工具。3.1 自动切换原理当主节点Primary故障时组内剩余节点检测到通信超时默认5秒触发重新选举选择新主节点按server_uuid字典序升序新主节点自动提升为读写模式应用层通过MySQL Router或VIP实现透明切换3.2 手动验证切换模拟主节点故障在node1执行# 直接kill掉mysqld进程kill-9$(pgrep mysqld)在node2观察切换-- 约5-10秒后自动选出新的PRIMARYSELECTMEMBER_HOST,MEMBER_ROLEFROMperformance_schema.replication_group_members;-- 输出显示某节点变为PRIMARY其他为SECONDARY3.3 应用层接入方案方案AMySQL Router官方推荐# 安装Routeryuminstallmysql-router# 配置路由cat/etc/mysqlrouter/mysqlrouter.confEOF [routing:primary] bind_address0.0.0.0 bind_port6446 destinationsmetadata-cache://mycluster/?rolePRIMARY protocolclassic [routing:secondary] bind_address0.0.0.0 bind_port6447 destinationsmetadata-cache://mycluster/?roleSECONDARY protocolclassic EOF# 启动后应用连接6446自动路由到主节点6447路由到从节点方案BVIP 自定义脚本#!/bin/bash# 简易VIP漂移脚本需配合keepalived或手动触发# 检测当前主节点绑定VIP到该节点VIP192.168.1.100PRIMARY$(mysql-eSELECT MEMBER_HOST FROM performance_schema.replication_group_members WHERE MEMBER_ROLEPRIMARY-s-N)# 在当前主节点执行ipaddradd$VIP/24 dev eth0四、运维关键操作手册4.1 监控指标Prometheus mysqld_exporter重点监控# 组复制延迟-mysql_global_status_group_replication_primary_elections# 选举次数-mysql_slave_status_seconds_behind_master# 复制延迟# 成员状态-mysql_global_status_group_replication_member_status# ONLINE/OFFLINE/ERROR4.2 日常维护命令-- 查看组复制事务统计SELECT*FROMperformance_schema.replication_group_member_stats;-- 优雅切换主节点计划内维护SELECTgroup_replication_set_as_primary(member_uuid);-- 节点离线维护后重新加入STOP GROUP_REPLICATION;STARTGROUP_REPLICATION;-- 从组中移除故障节点需在其他节点执行-- 注意被移除节点需重建数据才能重新加入4.3 数据备份策略即使MGR提供高可用仍需独立备份# 物理备份推荐Percona XtraBackup在Secondary节点执行xtrabackup--backup--target-dir/backup/$(date%Y%m%d)--userbackup--passwordxxx# 逻辑备份mysqldump用于小表或特定恢复场景mysqldump --single-transaction --master-data2--all-databasesfull_backup.sql五、避坑指南生产经验问题现象根因解决方案节点无法加入组报错This member has more executed transactions新节点GTID比现有组新清空新节点数据从现有节点克隆数据组复制频繁断开网络抖动或防火墙调整group_replication_member_expel_timeout延长驱逐超时事务提交变慢单主模式写放大检查网络延迟考虑多主模式仅非冲突场景脑裂多个Primary网络分区确保组通信端口互通使用仲裁节点5.7.22支持六、总结MGR作为MySQL官方高可用方案相比传统主从MHA架构有显著优势简化架构无需额外故障检测组件数据强一致基于Paxos的多数派确认自动故障转移秒级切换RPO≈0下一步建议测试环境完整演练故障切换场景配合MySQL Router实现应用透明接入建立完善的监控告警体系重点关注复制延迟和成员状态生产环境部署前务必在测试环境验证所有故障场景确保团队熟悉应急处理流程。本文配置基于MySQL 8.0.32验证不同版本参数可能略有差异建议参考官方文档最新版本。