MySQL MGR是基于Paxos协议的原生高可用方案，支持单主/多主模式，适合对强一致性和自动化运维要求高的中大型系统；部署需满足版本、GTID、binlog等条件，运维须监控成员状态、事务延迟等指标，常见问题多源于网络、参数配置及操作规范。
MySQL MGR 是什么，适合什么场景
MySQL Group Replication（MGR）是 MySQL 官方推出的基于 Paxos 协议的原生高可用方案，支持单主和多主模式。它通过分布式一致性协议自动处理节点故障、数据同步与角色切换，无需依赖外部中间件（如 MHA、Orchestrator），适合对数据强一致性和自动化运维有要求的中大型业务系统。
单主模式部署关键步骤
单主模式更稳定、兼容性更好，是生产环境主流选择。部署时需重点关注以下几点：
- 所有节点使用 MySQL 5.7.17+ 或 8.0.11+，建议统一小版本避免兼容问题
- 启用 binlog（binlog_format=ROW）、GTID（gtid_mode=ON、enforce_gtid_consistency=ON）
- 配置 group_replication_group_name（必须是合法 UUID）、本地地址（group_replication_local_address）和集群种子列表（group_replication_group_seeds）
- 首次启动需在引导节点执行 SET GLOBAL group_replication_bootstrap_group=ON，启动后立即设为 OFF
- 加入新节点前确保其数据与集群一致（推荐从 donor 全量克隆或使用备份恢复）
日常运维中必须监控的核心项
MGR 运维不是“部署完就没事”，以下状态指标需纳入监控告警体系：
- group_replication_member_state：应为 ONLINE，出现 RECOVERING / OFFLINE / UNREACHABLE 需立即排查网络或 IO 延迟
- group_replication_members：确认在线节点数及角色（PRIMARY 或 SECONDARY）
- performance_schema.replication_group_members 和 replication_group_member_stats：查看事务延迟（COUNT_TRANSACTIONS_IN_QUEUE）、冲突检测（COUNT_CONFLICTS_DETECTED）等内部指标
- 错误日志中频繁出现 “The member is being expelled from the group” 或 “Timeout while waiting for view change” 表示网络抖动或参数超时设置过短
常见故障与应对思路
实际运行中高频问题往往集中在网络、参数与操作规范上：
- 节点反复进出集群：检查防火墙是否放行 MGR 端口（默认 33061）、主机名解析是否稳定、group_replication_member_expel_timeout 是否过小（建议调至 10~30 秒）
- 写入卡顿或报错“Group replication is locked”：通常是主节点压力过大或事务过大，可限制单事务大小、开启 group_replication_flow_control_mode 并调低阈值
- 无法自动选主或主节点不切换：确认未启用多主模式且仅有一个 PRIMARY；检查 group_replication_autorejoin_tries 是否启用（8.0.16+ 支持自动重连）
- 备份恢复后无法加入集群：务必用 mysqldump --set-gtid-purged=ON 或物理备份工具（如 Percona XtraBackup）并正确注入 GTID_EXECUTED
