目 录回顾与导读从是什么到内部如何协作第一章 组复制架构总览1.1 一个复制组 三个层次1.2 组通信层MGR 的心脏1.3 与传统主从的架构对照第二章 Paxos 变体协议多数派与全局有序2.1 Paxos 协议的核心思想2.2 事务如何达成一致2.3 全局有序的意义第三章 组成员管理加入、离开与驱逐3.1 成员状态机3.2 成员加入流程3.3 成员离开与驱逐第四章 故障检测与网络分区处理4.1 故障检测GCS 心跳4.2 少数派与多数派失联的处理4.3 Xcom 消息缓存第五章 单主模式与多主模式5.1 单主模式默认推荐生产5.2 多主模式5.3 选主算法单主模式第六章 MGR 与主从复制的架构差异总结读者收获与下一步7.1 读完本篇你应该带走什么7.2 下一步建议回顾与导读从是什么到内部如何协作第一篇建立了 MGR 的整体认知官方基于 Paxos 的组复制方案RPO0、秒级切换、单主/多主双模式。但Paxos 究竟怎么工作成员如何加入和离开网络分区时组内发生了什么这些是这一篇要回答的问题。这一篇将深入 MGR 的物理与逻辑骨架组复制架构总览、Paxos 变体协议、组成员管理、故障检测与网络分区处理、单主/多主模式的工作机制以及与主从复制的架构差异。读完这一篇你将拥有工程师级别的 MGR 架构认知为第三篇的事务复制与冲突检测原理打下基础。第一章 组复制架构总览1.1 一个复制组 三个层次MGR 把一个 MySQL 集群组织成复制组Replication Group组内协作由三个层次共同完成组成员Members加入同一个复制组的 MySQL 实例彼此通过组通信层互联。主节点Primary单主模式下组内的唯一可写节点多主模式下所有成员都可写。组通信层Group Communication基于 Xcom 引擎的组通信系统负责消息广播、全局排序与故障检测。可以这样理解组成员是编委会的编辑主节点是本届主编组通信层是会议制度本身——所有决议事务都要通过会议制度组通信层达成共识。1.2 组通信层MGR 的心脏组通信层是 MGR 与主从复制最根本的架构差异所在。它基于 Xcom 引擎实现消息广播每个成员把事务消息广播给组内所有成员。全局排序通过 Paxos 协议为所有事务确定一个全局一致的顺序保证每个成员按相同顺序应用。故障检测通过 GCSGroup Communication System心跳实时感知成员存活状态。正是组通信层的广播 全局排序 心跳让 MGR 从机制上消灭了主从延迟窗口与外部切换依赖。1.3 与传统主从的架构对照对比维度传统主从复制MGR 组复制通信方式主库单向推送 Binlog 给从库组内双向广播全成员互联事务顺序各从库按收到顺序回放可能不一致Paxos 全局排序所有成员一致故障切换外部工具MHA 等组内自动选举一致性保证异步/半同步有窗口多数派确认RPO0第二章 Paxos 变体协议多数派与全局有序2.1 Paxos 协议的核心思想Paxos 是分布式系统中最经典的共识算法核心思想是少数服从多数一个提案只有被超过半数的成员接受才算达成共识。MGR 使用 Paxos 的变体实现组内事务的全局排序与提交确认。为什么多数派能保证一致因为任意两个多数派集合必然有交集——只要多数派节点记住了某个事务任何后续选举/查询都一定能看到它。这是 MGR 实现 RPO0 的数学基础。2.2 事务如何达成一致第一步写入节点发起事务将事务消息广播到组通信层。第二步Paxos 协议为事务分配全局序号并广播给所有成员。第三步多数派成员确认收到该事务并写入各自日志。第四步事务按全局序号在所有成员上应用写入节点收到提交确认。关键点提交的定义是多数派确认而非所有节点确认——这正是 MGR 能在少数节点故障时继续服务的原因多数派存活即可。2.3 全局有序的意义全局有序意味着任何时刻组内所有成员看到的事务顺序完全一致。对一致性所有成员数据最终一致不存在主从延迟窗口。对多主多个节点同时写入时全局序号解决谁先谁后的争议配合冲突检测第三篇详述。代价也很直接每次提交都要多数派确认写入路径比单机多一轮网络往返——这就是 MGR写放大的根源第六篇展开。第三章 组成员管理加入、离开与驱逐3.1 成员状态机每个成员的复制组状态由状态机管理最核心的三个状态状态含义典型场景ONLINE成员在线且正常参与组内复制健康运行的成员RECOVERING成员正在追赶数据加入组/落后追平新成员加入、成员恢复ERROR成员异常被驱逐或无法恢复网络故障、复制中断成员状态可通过 performance_schema.replication_group_members 表查询——这是 MGR 监控的第一入口第七篇详述。3.2 成员加入流程新成员发起加入请求组通信层将其纳入组视图。新成员进入 RECOVERING 状态从组内已有成员拉取增量数据基于 Binlog 追平。数据追平后状态切换为 ONLINE正式参与组内复制与投票。3.3 成员离开与驱逐正常离开成员主动退出组STOP GROUP_REPLICATION状态平滑移除。异常驱逐成员失联超过 group_replication_member_expel_timeout 时间被组内多数派判定为故障并从组视图驱逐。expel_timeout 是 MGR 最重要的参数之一太短会导致网络瞬断误驱逐太长会延迟故障感知——调优细节在第七篇。第四章 故障检测与网络分区处理4.1 故障检测GCS 心跳组通信层通过 GCS 心跳实时感知成员存活。成员超过阈值未上报心跳即被标记为可疑进入故障判定流程。与 MHA 的外部探测不同MGR 的故障检测内建于组通信层感知更直接、更及时。4.2 少数派与多数派失联的处理网络分区脑裂时MGR 通过 Paxos 的多数派原则自动处理多数派分区包含过半成员继续提供服务少数派分区被隔离/驱逐。少数派分区成员不足半数失去多数派无法达成共识该分区停止服务保证一致性优先。这正是 MGR 与 MHA 的根本差异MHA 的脑裂防护依赖外部脚本MGR 的脑裂防护内建于 Paxos——少数派自动让路从机制上杜绝双主。4.3 Xcom 消息缓存Xcom 引擎为组内消息维护缓存group_replication_message_cache在网络不稳定、成员暂时掉线时保存消息待成员恢复后补发。缓存容量有限大量消息积压可能导致缓存撑满触发成员被驱逐连锁故障。监控与调优缓存水位是 MGR 健康度的关键指标第六/七篇展开。第五章 单主模式与多主模式5.1 单主模式默认推荐生产组内只有一个主节点Primary可写其余成员只读。写入路径简单、无冲突风险是 MGR 生产环境的默认选择主节点故障组内自动选举新主选主算法见下文秒级切换。读写分离只读成员承接读流量配合 MySQL Router 实现路由。适用绝大多数高可用读写集群。5.2 多主模式组内所有成员都可写扩展写入能力写入路径任何成员接收写入事务广播到全组。冲突处理并发写同一行时通过写集冲突检测决定提交或回滚第三篇详述。适用写入分布分散、冲突率低的场景高频冲突业务慎用。对比维度单主模式多主模式可写节点仅主节点全部成员冲突风险无单写有需冲突检测写扩展受单节点限制可扩展运维复杂度低简单可靠高冲突治理生产建议默认首选按需评估5.3 选主算法单主模式单主模式下主节点故障后组内按以下优先级选举新主第一优先MySQL 版本避免日志回放冲突选版本一致的成员。第二优先节点权重group_replication_member_weight 参数可自定义优先级。最终兜底UUID 生成顺序完全平等的随机选择。理解选主算法才能在生产中通过权重参数控制谁成为新主第七篇调优会用上。第六章 MGR 与主从复制的架构差异总结把前五章的机制串起来MGR 与主从复制的架构差异可以浓缩为一张总表对比维度主从复制MGR 组复制数据流向主库 → 从库单向组内广播多向一致性机制Binlog 回放异步/半同步Paxos 共识多数派确认事务顺序各从库独立回放全局有序统一应用故障切换外部工具MHA 等组内自动选举脑裂防护依赖外部脚本Paxos 内置仲裁写入模式单主单主 / 多主一致性保证RPO0异步RPO0多数派一句话总结主从复制是单向复制 外部高可用的架构MGR 是组内共识 内置高可用的架构。MGR 不是把主从做得更好而是用分布式共识重构了复制的底层逻辑——这正是它作为 8.0 官方方案的底气所在。读者收获与下一步7.1 读完本篇你应该带走什么MGR 组成员 主节点 组通信层Xcom组通信层是心脏。Paxos 多数派确认是 RPO0 的数学基础任意两个多数派必有交集。成员状态机ONLINE/RECOVERING/ERROR与 expel_timeout 决定成员如何进出组。脑裂由 Paxos 内置仲裁多数派继续、少数派停服杜绝双主。单主模式是生产默认多主模式需按冲突率评估选主按版本 → 权重 → UUID。7.2 下一步建议下一篇将深入 MGR 的事务层原理单主模式下事务如何复制、多主模式冲突检测写集如何工作、流控机制如何反向压速、消息缓存如何兜底。这是 MGR 系列最硬核的一篇。