MySQL Group Replication (MGR) 在主节点（单主模式下）故障时，其自动故障切换（Failover） 的核心在于其分布式故障检测机制和基于最新数据的共识选举协议。整个过程高度自动化，旨在最小化人工干预和停机时间。
以下是主节点故障自动切换的实现细节和选举过程：
一、触发条件：故障检测
-
持续心跳监控 (Failure Detector)：
- 组内每个成员会定期（默认每秒）通过专用的组通信网络通道向其他成员发送心跳消息（包含自身状态和最新事务信息）。
- 每个成员都会监听来自其他成员的心跳。
-
超时判定故障：
- 如果某个成员（比如当前的Primary，称为
Node_A）在预设的超时时间（如 5秒，由参数group_replication_member_expel_timeout控制）内未收到来自某个特定成员（比如Node_B）的任何消息（包括心跳和应用进度等有效消息）。
- 如果某个成员（比如当前的Primary，称为
-
嫌疑阶段（Suspicion Phase - 分布式检测）：
- 超时后，检测到问题的成员（
Node_B）并不会立即宣布Node_A失效。 Node_B会向整个组广播一个怀疑消息，指出它认为Node_A可能失效了。（这是一种优化的“流言传播”或Gossip-like机制）
- 超时后，检测到问题的成员（
-
确认故障 (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 引擎驱动，遵循一个严格的、基于分布式共识的顺序规则来选择新主：
-
收集候选节点状态： 剩余的在线节点（构成 Quorum 的成员）会交换和比较彼此的状态信息，最关键的两个值是：
-
last_applied_seq_no(或类似的最高事务序列号): 每个节点上已应用的最高事务的序列号（通常直接取自 GTID Executed Set 中的内部序号，或事务计数器）。这个值代表了节点上数据的相对“新旧”程度。数值越大，数据越新。 -
server_uuid: 每个 MySQL 服务器实例的唯一标识符（全局唯一字符串）。
-
-
比较规则：
- 第一优先级：
last_applied_seq_no(值更高者优先)- 目标：选择具有最新数据（拥有最多已提交事务）的节点作为新主。这最大限度地避免了数据丢失（因为新主理论上包含了旧主最后提交的所有事务）。
- 第二优先级：
server_uuid(字典序更小者优先)- 在出现多个节点拥有 完全相同的 最高的
last_applied_seq_no值的情况时（通常只发生在完美同步或启动时），选举算法会回退到比较server_uuid，选择字典序更小的（即server_uuid字符串排序更靠前）的节点作为新主。这是一种确定性的最终解决机制。
- 在出现多个节点拥有 完全相同的 最高的
- 第一优先级：
-
达成共识：
- XCom 引擎负责协调这个比较和决策过程。
- 剩余的每个在线节点独立应用上述比较规则，最终在所有节点上达成完全一致的选举结果。这个过程基于共识协议（类似 Paxos），确保所有在线节点都选出同一个新主节点。
-
角色切换：
- 被选中的节点（如
Node_C）自动将其角色从SECONDARY切换为PRIMARY。 - 其他剩余节点（如
Node_B,Node_D）保持为SECONDARY（只读）角色，并准备接受来自新主Node_C的复制数据。
- 被选中的节点（如
核心原则：选数据最新的节点当新主！
last_applied_seq_no是选择的核心依据，server_uuid用于处理平局。
三、集群视图更新与服务恢复
-
更新元数据：
- 组内形成新的成员视图（删除了故障节点
Node_A，并包含了新主Node_C）。 - 新的视图（
group_replication_group_members）信息通过共识协议自动同步给所有剩余节点。
- 组内形成新的成员视图（删除了故障节点
-
MySQL Router 重定向：
- MySQL Router 实例在后台定期轮询集群元数据（
mysql_innodb_cluster_metadataschema 或 performance_schemagroup_replication_group_members）。 - 当 Router 检测到集群视图更新（
ROLE列显示新的PRIMARY是Node_C）时，它会立即更新内部路由表。 - 对于新连接： 所有新到达的读写请求自动路由到新主
Node_C。 - 对于现有连接： Router 会尝试关闭或终止指向旧主
Node_A的会话（通常在旧连接下次发生读写操作时返回错误或自动重连到 Router，由 Router 重定向到Node_C）。
- MySQL Router 实例在后台定期轮询集群元数据（
-
应用恢复（Applier 继续）:
- SECONDARY 节点上的 Applier 线程继续从新的 PRIMARY (
Node_C) 接收并应用 binlog events，追赶数据。
- SECONDARY 节点上的 Applier 线程继续从新的 PRIMARY (
四、故障切换流程图（简版）
总结关键点
-
前提：剩余节点构成 Quorum（ > N/2 ）。
-
故障检测：基于心跳超时 + 分布式投票驱逐。
-
选举核心：
last_applied_seq_no（选数据最新者）。 -
平局处理：
server_uuid（小者优先）。 -
自动化：整个过程（检测 -> 驱逐 -> 选举 -> 切换 -> 视图更新）由 MGR 自动完成。
-
切换时间：通常在旧主失效被确认（
group_replication_member_expel_timeout时间已过）后，选举本身非常快（毫秒级），加上通知Router和应用重建连接，客户端感知的中断时间通常在 20-60 秒**。 -
透明性：应用通过 MySQL Router 连接，Router 会自动重定向流量到新主。
因此，MGR 通过可靠的分布式故障检测机制和基于最新数据优先的共识选举协议，实现了高可用的自动故障切换（Failover）。
浙公网安备 33010602011771号