MySQL MGR高可用
MySQL Group Replication（MGR）是 MySQL 提供的高可用解决方案，基于 Paxos 算法实现分布式协调。
适用场景：需要自动故障转移的高可用 MySQL 集群、读写分离架构、分库分表中的高可用分片。MGR 要求所有表必须使用 InnoDB 引擎且有主键，建议配合 MaxScale 中间件实现读写分离。
核心要点
MySQL Group Replication高可用架构与实践，基于Paxos算法
MGR 架构
MGR 是具备强大分布式协调能力的 MySQL 插件，可用于创建弹性、高可用性、高容错的复制拓扑。
插件组成
| 组件 | 功能 |
|---|---|
| Capture | 负责事务状态在集群内提交或回滚 |
| Applier | 代表集群 Secondary 节点 Binlog 回放 |
| Recovery | 代表崩溃恢复或集群扩容时增量数据同步 |
| GCS | 基于 Paxos 的原子广播协议 |
通讯协议
基于 Paxos 算法的 GCS（Group Communication System）原子广播协议，保证了一条事务在集群内要么在全部节点上提交，要么全部回滚。
组成员资格
MGR 内部提供视图服务，集群节点之间相互交换各自的视图信息，实现集群整体的稳态。
数据一致性
MGR 内部实现了不同事务之间修改数据的冲突认证检测机制。在集群的所有节点当中进行冲突认证检测，通过认证的事务即可提交成功。
单主模式与多主模式
单主模式
只有一个节点可以接受写操作，其他节点只读。
多主模式
所有节点都可以接受写操作，但需要处理更复杂的冲突场景。
事务认证模式
MGR 通过冲突认证机制保证集群数据一致性，认证模式决定了事务在集群内的回放顺序（注意：这不是 SQL 标准的事务隔离级别 READ-COMMITTED 等）。
| 模式 | 描述 |
|---|---|
| BEFORE | 等待先序事务回放完成后再执行 |
| AFTER | 先序事务回放完成后，后序事务开始执行 |
| BEFORE_AND_AFTER | 同时等待先序事务回放，且后序事务等待当前事务回放 |
| BEFORE_ON_PRIMARY_FAILOVER | 切换时阻塞连接新主的等待先序事务 |
流控机制
基本队列
- 认证队列：事务在认证阶段的队列
- 二进制日志应用队列：事务在回放阶段的队列
流控触发与过程
当其中一个队列的大小超过用户定义的阈值时，触发流量控制：
- 根据上一阶段延迟的事务数量逐步减少 10%，让队列减小到阈值之内
- 不影响阈值内的事务，但会延迟超过阈值的事务
- 阈值设置非常小时，部分事务延迟可能接近一个完整监控周期
根据不同的业务场景（读多写少、写多读少、读写均衡），选择不同的流控配置。
适用场景
弹性复制
需要灵活的复制基础设施，MySQL Server 数量必须动态增减，且对业务副作用尽可能少。
高可用分片
分片是实现写扩展的流行方法。基于 MGR 实现的高可用分片，每个分片映射到一个复制组上。
替代主从复制
使用一个主库会造成单点争用时，向整个组内多个成员同时写入数据可以避免。
MaxScale 读写分离
MGR 集群本身不保证业务的写入重定向，可以在 MGR 集群上加一个读写分离中间件 MaxScale。
MaxScale 会自动探测 MGR 集群里 Primary 节点状态，如果发生高可用切换或 Primary 节点宕机，会重新探测选取新的 Primary 节点，然后自动将业务写请求重定向到新的 Primary 节点。
常见问题
节点被驱逐出组
节点网络抖动或响应超时会被 MGR 驱逐。检查 group_replication_member_status 显示是否为 ONLINE，使用 SET GLOBAL group_replication_recover_from_all_gcs_errors = 1 尝试重新加入。
多主模式写冲突
多主模式下两个节点同时修改同一行会触发冲突检测，后提交的事务被回滚。应用层需要处理回滚重试逻辑，或改用单主模式避免冲突。
数据延迟
从节点回放速度跟不上主节点写入速度时，可通过流控机制调节。调整 group_replication_flow_control_certifier_threshold 和 group_replication_flow_control_applier_threshold 参数控制队列阈值。