MySQL Group Replication (MGR) 主节点故障自动切换和选举过程

MySQL Group Replication (MGR) 在主节点（单主模式下）故障时，其​​自动故障切换（Failover）​​ 的核心在于其​​分布式故障检测机制​​和​​基于最新数据的共识选举协议​​。整个过程高度自动化，旨在最小化人工干预和停机时间。

以下是主节点故障自动切换的实现细节和选举过程：

---

​​一、触发条件：故障检测​​

1. ​​持续心跳监控 (Failure Detector)：​​

   • 组内每个成员会​​定期​​（默认每秒）通过专用的​​组通信网络通道​​向其他成员发送心跳消息（包含自身状态和最新事务信息）。
   • 每个成员都会​​监听​​来自其他成员的心跳。

2. ​​超时判定故障：​​

   • 如果某个成员（比如当前的Primary，称为Node_A）在​​预设的超时时间​​（如 5秒，由参数 group_replication_member_expel_timeout 控制）内​​未收到​​来自某个特定成员（比如Node_B）的任何消息（包括心跳和应用进度等有效消息）。

3. ​​嫌疑阶段（Suspicion Phase - 分布式检测）：​​

   • 超时后，检测到问题的成员（Node_B）并不会立即宣布 Node_A 失效。
   • Node_B 会向整个组​​广播一个怀疑消息​​，指出它认为 Node_A 可能失效了。（这是一种优化的“流言传播”或Gossip-like机制）

4. ​​确认故障 (Expulsion)：​​

   • 组内其他成员收到Node_B的怀疑消息后，会检查自己与Node_A的最后通信时间。
   • 如果​​大多数在线成员​​（构成法定数量Quorum）都确认在group_replication_member_expel_timeout时间内未收到Node_A的有效消息，那么这些成员将达成共识。
   • 达成共识后，组会​​自动驱逐（Expel）​​ Node_A。Node_A 的状态被标记为 UNREACHABLE 然后 OFFLINE（或 ERROR），并从组视图（group_replication_group_members）中移除。

​​关键点：故障检测是分布式的，避免单点判断错误；驱逐需要多数派（Quorum）成员确认。​​

---

​​二、新主节点选举（Leader Election）​​

一旦确认旧主节点（Node_A）被驱逐，并且剩余的​​在线成员数量仍然超过半数（拥有 Quorum）​​，集群会​​自动触发新主节点（Primary）的选举过程​​。

​​核心选举算法：基于“最高事务序列号(seq_no) + 唯一标识(server_uuid)”​​

MySQL MGR 的选举过程由底层 XCom 引擎驱动，遵循一个严格的、基于分布式共识的顺序规则来选择新主：

1. ​​收集候选节点状态：​​ 剩余的在线节点（构成 Quorum 的成员）会交换和比较彼此的状态信息，最关键的两个值是：

   • ​​last_applied_seq_no (或类似的最高事务序列号):​​ 每个节点上​​已应用的最高事务的序列号​​（通常直接取自 GTID Executed Set 中的内部序号，或事务计数器）。这个值代表了节点上数据的​​相对“新旧”程度​​。数值越大，数据越新。
   • ​​server_uuid:​​ 每个 MySQL 服务器实例的唯一标识符（全局唯一字符串）。

2. ​​比较规则：​​

   • ​​第一优先级：last_applied_seq_no (值更高者优先)​​
     • 目标：​​选择具有最新数据（拥有最多已提交事务）的节点​​作为新主。这最大限度地避免了数据丢失（因为新主理论上包含了旧主最后提交的所有事务）。
   • ​​第二优先级：server_uuid (字典序更小者优先)​​
     • 在出现多个节点拥有 完全相同的 最高的 last_applied_seq_no 值的情况时（通常只发生在完美同步或启动时），选举算法会回退到比较 server_uuid，选择字典序更小的（即 server_uuid 字符串排序更靠前）的节点作为新主。这是一种确定性的最终解决机制。

3. ​​达成共识：​​

   • XCom 引擎负责协调这个比较和决策过程。
   • 剩余的每个在线节点独立应用上述比较规则，最终在所有节点上达成​​完全一致的选举结果​​。这个过程基于共识协议（类似 Paxos），确保所有在线节点都​​选出同一个新主节点​​。

4. ​​角色切换：​​

   • 被选中的节点（如 Node_C）自动将其角色从 SECONDARY 切换为 PRIMARY。
   • 其他剩余节点（如 Node_B, Node_D）保持为 SECONDARY（只读）角色，并准备接受来自新主 Node_C 的复制数据。

​​核心原则：选数据最新的节点当新主！last_applied_seq_no 是选择的核心依据，server_uuid 用于处理平局。​​

---

​​三、集群视图更新与服务恢复​​

1. ​​更新元数据：​​

   • 组内形成新的成员视图（删除了故障节点Node_A，并包含了新主Node_C）。
   • 新的视图（group_replication_group_members）信息通过共识协议自动同步给所有剩余节点。

2. ​​MySQL Router 重定向：​​

   • MySQL Router 实例在后台​​定期轮询​​集群元数据（mysql_innodb_cluster_metadata schema 或 performance_schema group_replication_group_members）。
   • 当 Router 检测到集群视图更新（ROLE 列显示新的 PRIMARY 是 Node_C）时，它会​​立即更新内部路由表​​。
   • ​​对于新连接：​​ 所有新到达的读写请求自动路由到新主 Node_C。
   • ​​对于现有连接：​​ Router 会尝试关闭或终止指向旧主 Node_A 的会话（通常在旧连接下次发生读写操作时返回错误或自动重连到 Router，由 Router 重定向到 Node_C）。

3. ​​应用恢复（Applier 继续）:​​

   • SECONDARY 节点上的 Applier 线程继续从新的 PRIMARY (Node_C) 接收并应用 binlog events，追赶数据。

---

​​四、故障切换流程图（简版）​​

---

​​总结关键点​​

1. ​​前提：剩余节点构成 Quorum（ > N/2 ）。​​

2. ​​故障检测：基于心跳超时 + 分布式投票驱逐。​​

3. ​​选举核心：last_applied_seq_no（选数据最新者）。​​

4. ​​平局处理：server_uuid（小者优先）。​​

5. ​​自动化：整个过程（检测 -> 驱逐 -> 选举 -> 切换 -> 视图更新）由 MGR 自动完成。​​

6. ​​切换时间：通常在旧主失效被确认（group_replication_member_expel_timeout时间已过）后，选举本身非常快（毫秒级），加上通知Router和应用重建连接，​​客户端感知的中断时间通常在 20-60 秒​**​。

7. ​​透明性：应用通过 MySQL Router 连接，Router 会自动重定向流量到新主。​​

​​因此，MGR 通过可靠的分布式故障检测机制和基于最新数据优先的共识选举协议，实现了高可用的自动故障切换（Failover）。​​