MySQL Group Replication（MGR）的核心工作原理在于它实现了 基于 Paxos 变种协议（组通信系统引擎XCom）的、原子广播（Atomic Broadcast）的多主/单主强同步复制机制。它将传统的异步主从复制提升到了一个多节点协同、高一致性的分布式系统层级。
以下是其工作原理的关键环节：
-
组成员（Group Membership）：
- 多个 MySQL 服务器（通常至少3个）组成一个 “组”（Group）。每个节点都运行着 Group Replication 插件。
- 组内成员自动管理加入和退出。每个成员都知道组内其他所有成员的状态（ONLINE，RECOVERING，UNREACHABLE, OFFLINE, ERROR等）。
- 成员之间通过专用网络通道进行通信（组复制通信栈）。
-
组通信引擎（XCom）：
- 这是 MGR 的底层核心组件，实现了确保消息可靠、有序传递的分布式共识协议（基于Paxos变种）。
- 关键功能： 负责在整个组内对消息（主要是二进制日志事务事件）进行原子广播（Atomic Broadcast）。这意味着：
- 全有或全无： 消息要么被成功传递到组内的每个 ONLINE 节点，要么任何节点都未成功传递（提供原子性）。
- 可靠有序： 消息以完全相同的全局顺序传递到所有 ONLINE 节点（提供一致性）。即使出现网络中断或节点故障，只要通信恢复后重新达成共识，新消息也会按相同的总序追加。
- XCom 利用 “多数派原则（Quorum）” 来达成共识。任何事务要在组内提交，必须获得大多数（N/2+1，N为组大小）节点的投票确认。这确保了网络分区时最多只有一个多数派子组能够继续工作（避免“脑裂”），并提供了容错能力（例如，3节点容忍1个节点故障，5节点容忍2个节点故障）。
-
事务生命周期（以单主模式写Primary节点为例）：
- 本地执行与写入日志： 客户端发起一个写事务，在当前的主节点（Primary） 上执行SQL语句。和单机一样，数据首先在引擎层面修改并生成 Undo/Redo 日志。
- Prepare & Write Binlog： 事务准备提交时（进入提交阶段），主节点将其对应的所有修改事件（Binary Log Events）写入本地的 binlog 文件（写入 Page Cache）。此时事务数据尚未持久化（sync_binlog=0）到磁盘（为了性能）。
- 广播 & 收集认证（Certification）：
- 主节点将通过 Group Replication Channel 将包含这些 binlog events 的消息广播给组内所有其他节点（包括自己）。
- 所有节点收到消息后，首先进行 “冲突检测（Certification）”：
- 将接收到的事务标识符（包括主节点的
server_uuid和该节点的事务序列号seq_no）与本地的 “已认证事务集” 进行比对。 - 检查该事务修改的数据是否与当前节点上已经提交的并发（时间段有重叠） 事务修改了相同的行（Row-Level），但来自不同的节点（依赖写入集
WRITESET和gtid_executed）。 - 若无冲突： 该事务在该节点上获得预认证通过，计入“已认证事务集”。
- 若有冲突： 该事务被标记为失败（会在主节点上回滚）。
- 将接收到的事务标识符（包括主节点的
- 达成共识 & 投票：
- 所有节点（包括主节点自己）在完成本地的冲突检测后，会独立地对广播消息（事务是否可应用）进行投票（通常是“准备就绪”或“有冲突”）。
- XCom 引擎负责收集这些投票。
- 当主节点收到 超过半数组成员（包括主节点自己） 的“准备就绪”确认消息时，意味着该事务在组内达成了共识（多数派节点认为事务无冲突且可以应用）。此时主节点知道该事务可以安全地在组内提交。
- 主节点提交（Commit）：
- 主节点收到足够多的投票后，执行真正的事务提交操作（
COMMIT）。 - 确保 Binlog Event 和 数据更改通过 fsync 持久化到磁盘（此时 sync_binlog 设置才生效，但 MGR 依赖内部保障）。
- 向客户端返回“事务成功”信息。注意：客户端在收到成功响应时，意味着事务已在组内达成共识并持久化在主节点上，但尚未在所有从节点上持久化。
- 主节点收到足够多的投票后，执行真正的事务提交操作（
- 从节点应用（Apply）：
- 其他节点（副本节点，Secondary）在本地冲突检测通过后，就已经将事务对应的 binlog events 写入本地的 relay log 文件（写入 Page Cache）。
- 当它们收到主节点“已达成共识”的指示（隐含在协议的推进中），就知道该事务在主节点已提交。
- 副本节点上的回放线程（Applier Thread） 开始读取并应用 relay log 中的事件，将这些更改写入本地数据库（在数据页和引擎层持久化）。这通常是异步发生的，但 MGR 的一致性级别设置可影响应用的时机。
- 最终一致性保证： 因为事务是按全局一致、全序（binlog event order） 到达每个节点的，并且应用过程是串行的，所以所有在线且稳定的节点最终都会拥有一致的状态（相同的数据和事务提交顺序）。
-
自动故障转移（Failure Detection & Failover - 单主模式下）：
- 组内成员持续相互监控（通过心跳消息）。
- 如果某个成员（尤其是主节点）长时间没有心跳或被多数派判断为失效，它会被自动驱逐（Expelled） 出组。
- 如果失效的是主节点，剩余的在线节点（需要构成多数派）会自动协商并触发一次新的选举。
- 选举算法基于 server_uuid + 事务序列号（seq_no）排序：选择具有最新状态（拥有最高 seq_no，即最多已提交事务）的节点为新主（Primary）。如果多个节点具有相同的 seq_no，则选择 server_uuid 最小的节点。这样确保了新主拥有所有已提交事务。
- 自动重新配置： 组拓扑自动更新，所有剩余节点和连接到此组的 Router 都会感知到新的主节点是谁。
- 客户端（通过 Router）透明地重定向到新的主节点。
关键特性总结：
-
分布式一致性： 保证组内所有节点在稳定状态下拥有完全相同的数据视图和严格一致的提交顺序。
-
基于共识的高可用： 使用多数派原则（Paxos-like）达成共识，提供自动化的成员管理和主节点选举。
-
内置冲突检测（多主模式）： 检测并解决不同节点并发修改同一行数据引起的冲突。
-
故障容错： 可以容忍 (N-1)/2 个节点的失败（N为总节点数）。
-
灵活模式： 支持单主模式（推荐）（一个节点处理所有写）和多主模式（所有节点可读写，需小心冲突处理）。
-
性能折衷： 强一致性通过同步通信（消息广播、冲突检测、等待多数派投票）实现，相对于异步复制会带来额外的网络延迟开销。网络性能和稳定性对 MGR 的效率和可用性至关重要。
核心流程简化记忆：
客户端写操作 -> 主节点执行 -> 主节点写binlog -> 广播事务到组 -> 所有节点进行冲突检测(Certification) -> 所有节点对事务投票 -> 主节点收集投票 -> 达到多数派同意 -> 主节点提交(持久化) -> 返回客户端成功 -> 从节点异步应用更改
理解 XCom 引擎的原子广播协议和分布式共识、内置的冲突检测/解决机制（Certification）、以及基于多数派决策的故障转移机制，是掌握 MySQL Group Replication 工作原理的核心。
浙公网安备 33010602011771号