MySQL MGR高可用
MySQL Group Replication（MGR）是 MySQL 提供的高可用解决方案，基于 Paxos 算法实现分布式协调。
Paxos 是什么：一种分布式一致性协议，核心思想是多数派投票——超过半数节点同意，决策即生效。因此只要集群中过半节点存活，就能对"事务是否提交""谁是主节点"达成一致，少数节点故障不影响整体决策。MGR 用它在多个节点间同步事务和选主。
适用场景：需要自动故障转移的高可用 MySQL 集群、读写分离架构、分库分表中的高可用分片。MGR 要求所有表必须使用 InnoDB 引擎且有主键，建议配合 MaxScale 中间件实现读写分离。
与普通主从复制的区别
普通主从复制是异步的：主库提交事务后立即返回，从库异步回放 binlog，主库宕机时未同步的从库会丢数据、切换需人工干预。MGR 把复制升级为组内强协调：事务提交前先经 Paxos 广播到组内多数节点，从节点回放后再返回；主节点宕机时剩余节点自动投票选出新主，全程无需人工切换。代价是每次事务提交多一轮组内通信，写入延迟高于异步复制。
核心要点
MySQL Group Replication高可用架构与实践，基于Paxos算法
MGR 架构
MGR 是具备强大分布式协调能力的 MySQL 插件，可用于创建弹性、高可用性、高容错的复制拓扑。
插件组成
| 组件 | 功能 |
|---|---|
| Capture | 负责事务状态在集群内提交或回滚 |
| Applier | 代表集群 Secondary 节点 Binlog 回放 |
| Recovery | 代表崩溃恢复或集群扩容时增量数据同步 |
| GCS | 基于 Paxos 的原子广播协议 |
通讯协议
多个节点同时提交事务时，如果各节点看到的提交顺序不一致，数据就会分叉——这是分布式系统最经典的一致性难题。MGR 用基于 Paxos 的 GCS（Group Communication System）原子广播协议化解：一条事务经 Paxos 投票确认后，要么被组内所有节点一致接受并提交，要么全部拒绝回滚，不会出现"部分节点提交、部分节点没提交"的分裂状态，且所有节点按同一顺序回放，数据始终保持一致。
代价是事务提交要等多数节点确认，所以 MGR 的写入延迟高于普通主从复制——这也是"强一致"标签的由来。
组成员资格
集群里随时可能发生节点加入、退出、宕机，每个节点都必须知道"现在到底有哪些节点在服务"，否则投票基数和故障转移的目标都不明确。GCS 的视图服务负责维护这份成员名单：每个节点广播自己的存活状态，所有节点据此维护一致的视图；任何成员变化都会触发视图更新并广播给全组。
网络分区时部分节点可能看到不同的成员名单，这正是 Paxos 多数派机制要兜底的场景——只要过半节点还能互通，集群就照常运转。
数据一致性（冲突认证）
多主模式下两个节点可能同时修改同一行。流程是：事务在本地执行后，经 GCS 广播读写集合（改了哪些行）给组内所有节点；各节点用本事务的写集合与已认证事务的写集合比对，发现写写冲突则后提交的事务被回滚，无冲突则全部节点按同一顺序回放。这就是 MGR 在无锁协作下保证集群数据一致的方式。
单主模式与多主模式
单主模式
只有一个节点可以接受写操作，其他节点只读，由 Paxos 保证任意时刻只有一个 Primary。写入无冲突、实现简单，是最常用的部署形态，适合绝大多数 OLTP 业务。
多主模式
所有节点都可以接受写操作，写入分散到多个节点、无单点争用，但需要面对更复杂的写冲突场景——同一行被不同节点同时修改时，后提交者回滚。适合写压力大、且业务能容忍冲突重试的场景。
事务认证模式
认证模式控制事务在从节点上的回放时机与可见性（注意：这不是 SQL 标准的事务隔离级别 READ-COMMITTED 等）。
| 模式 | 含义 |
|---|---|
| BEFORE | 事务提交前，等待所有先序事务在组内回放完成——确保提交后读到的数据已包含此前事务的修改 |
| AFTER | 事务提交后，等待自己的修改在组内回放完成——确保后续读能立刻读到本事务的写入 |
| BEFORE_AND_AFTER | 前后都等待，最强一致性，延迟也最高 |
| BEFORE_ON_PRIMARY_FAILOVER | 平时不等待，仅在主节点切换场景启用 BEFORE 语义，防止切主后读到旧主未同步的数据 |
流控机制
基本队列
- 认证队列：事务在认证阶段的队列
- 二进制日志应用队列：事务在回放阶段的队列
流控触发与过程
当其中一个队列的大小超过用户定义的阈值时，触发流量控制：
- 根据上一阶段延迟的事务数量逐步减少 10%，让队列减小到阈值之内
- 不影响阈值内的事务，但会延迟超过阈值的事务
- 阈值设置非常小时，部分事务延迟可能接近一个完整监控周期
根据不同的业务场景（读多写少、写多读少、读写均衡），选择不同的流控配置。
适用场景
弹性复制
业务量是波动的：大促要扩容、活动结束要缩容，MySQL 节点数量必须跟着动态增减。传统主从复制加减节点要手动配置复制关系、停机切换，操作重且影响线上业务。
MGR 的组成员资格由 Paxos 自动管理：新节点启动后自动入组，经 Recovery 组件先做全量备份、再追组内已提交的 binlog 增量，追平后即成为正式成员参与投票；节点退出则主动离组，其余节点自动更新成员视图、继续对外服务，全程无需改配置。需要留意的是，节点入组的耗时取决于数据量，期间该节点不提供读写；组内节点数还受多数派约束（通常至少 3 个，过半存活才能选主），缩容不能低于这个下限。
高可用分片
单机 MySQL 的写能力有上限，数据量或写入压力上来后，就得把数据按分片键切到多个"分片"上水平扩展。MGR 的分片方案是让每个分片对应一个复制组：分片内部由 MGR 保证高可用（自动选主、自动故障转移），分片之间相互独立、互不影响，写扩展就是"加分片"。
分片键的选择直接决定数据分布是否均匀；跨分片的查询和事务需要应用层或 ShardingSphere/MyCat 等中间件协调，不像单机那样透明。
替代主从复制
单主架构下所有写请求都压在同一台主库上，写压力集中，主库也成了明显的单点。MGR 多主模式让组内多个成员同时接受写请求，把写压力分散到多个节点，从架构上消除单点写瓶颈。
代价是引入了写写冲突——同一行被不同节点同时修改时，后提交的事务会被回滚，应用必须能处理重试；因此不少场景权衡后仍选单主模式：它写入无冲突，只是把单点从"一台机器"变成了"Paxos 选出的主"。
MaxScale 读写分离
MGR 集群本身不保证业务的写入重定向，可以在 MGR 集群上加一个读写分离中间件 MaxScale。
MaxScale 会自动探测 MGR 集群里 Primary 节点状态，如果发生高可用切换或 Primary 节点宕机，会重新探测选取新的 Primary 节点，然后自动将业务写请求重定向到新的 Primary 节点。
常见问题
节点被驱逐出组
节点网络抖动、响应超时或长时间不参与心跳，会被组内其他节点视为失联并从成员视图中移除——否则失联节点继续参与投票会造成脑裂。处理时先检查 group_replication_member_status 是否为 ONLINE；确认网络恢复后，用 SET GLOBAL group_replication_recover_from_all_gcs_errors = 1 让节点重新入组并追赶落后的数据。
多主模式写冲突
多主模式下不同节点同时修改同一行，两个事务都认为自己"先到"，MGR 的冲突认证按提交顺序裁决，后提交的事务被回滚。应用层需要捕获回滚异常并重试；若业务难以接受冲突回滚，应改用单主模式，或按业务维度（用户、订单）把写路由固定到某个节点，从源头避免同一行被多节点写。
数据延迟
从节点回放 binlog 的速度跟不上主节点写入时，认证/回放队列会堆积，从节点数据滞后，读流量可能读到旧数据。流控机制用来反向压制写入：调整 group_replication_flow_control_certifier_threshold（认证队列阈值）和 group_replication_flow_control_applier_threshold（回放队列阈值），队列超阈值时主节点自动降速，让从节点追上。