为什么已提交的数据一定存在于多数节点

一、先明确两个核心定义

1. 已提交的数据：

   • 对 Raft 来说：Leader 收到 超过半数节点 的日志复制确认后，才会标记这条日志为「已提交」，并返回客户端成功。
   • 对 MySQL 半同步来说：主库收到 至少 1 个从库 的日志接收确认（ACK）后，才会向客户端返回 commit ok（3 节点集群下，主 + 1 从 = 多数派）。

2. 多数节点：

   多数派的阈值是 ⌊N/2⌋ + 1（N 是集群总节点数）。

   • 3 节点集群 → 多数派 = 2 个节点
   • 5 节点集群 → 多数派 = 3 个节点

二、核心原因：提交规则强制要求数据写入多数节点

无论是 Raft 原生逻辑，还是你配置的 MySQL 半同步，数据 “提交成功” 的前提，就是已经写入了多数节点。

1. Raft 层面的保证（算法规则）

Raft 对「已提交日志」的定义非常严格：

Leader 只有在收到 超过半数节点 对某条日志的复制确认后，才能将这条日志标记为「已提交」。

这个规则直接决定了：

• 一条日志只要被标记为「已提交」，就必然存在于 至少 ⌊N/2⌋ + 1 个节点 上。
• 数学上可以证明：任意两个多数派集合，必然存在交集 → 只要集群还有多数节点存活，就一定能找到这条已提交的日志。

2. MySQL 半同步层面的保证（你的配置）

你在 MySQL 里配置的 rpl_semi_sync_master_wait_for_slave_count = 1，就是把 Raft 的提交规则落地到了数据库：

• 3 节点集群中，主库 + 1 个从库 = 2 个节点（多数派）。
• 主库必须等从库确认 “收到并写入中继日志”，才会返回客户端写入成功。

这一步直接强制：客户端感知到的「已提交数据」，已经存在于主库 + 至少 1 个从库 → 多数节点。

举个5 节点集群的直观例子

先明确核心前提：

1. 5 节点集群多数派阈值 = ⌊5/2⌋+1=3 → 必须 至少 3 个节点在线 才能选主、才能确认数据提交。
2. 搭配 MySQL 半同步复制，配置 rpl_semi_sync_master_wait_for_slave_count=2 → 主库必须等 2 个从库确认接收日志，才算提交成功（主 + 2 从 = 3 个节点，满足多数派）。
3. 集群角色：A(主)、B(从)、C(从)、D(从)、E(从)

一、正常写入流程（保证已提交数据存于多数节点）

步骤 1：客户端发起写请求

客户端向主库 A 发送 INSERT INTO user (name) VALUES ('test') 语句。

步骤 2：主库生成日志并同步

1. 主库 A 将这条 SQL 写入本地 binlog，生成 GTID：GTID1。
2. 主库 A 同时将 GTID1 日志同步给所有从库 B/C/D/E。

步骤 3：半同步等待多数派确认

主库 A 等待从库返回 ACK 确认（日志已写入从库 relay log）：

• 从库 B 先收到日志，写入 relay log，返回 ACK。
• 从库 C 随后收到日志，写入 relay log，返回 ACK。
• 此时主库 A 已收到 2 个从库的确认 → 主库 A + 从库 B/C = 3 个节点（满足多数派阈值）。

步骤 4：数据提交，返回客户端成功

1. 主库 A 执行 commit，标记 GTID1 为 已提交。
2. 主库 A 向客户端返回 写入成功。
3. 从库 B/C/D/E 随后执行 relay log 中的 GTID1，同步数据。

关键结论

此时 已提交数据 GTID1 至少存在于 A/B/C 3 个节点（多数节点），就算任意 2 个节点宕机，数据也不会丢。

二、主库故障 + 自动选主流程（Raft 核心）

假设主库 A 突然宕机，集群触发选主：

步骤 1：探测主库故障

Operator 的 Reconcile 循环探测到 A 无法连接 → 判定主库故障。

步骤 2：过滤健康节点，检查多数派

1. 健康节点：B/C/D/E（4 个节点，远大于多数派阈值 3）。
2. Operator 确认满足多数派 → 允许发起选举。

步骤 3：Raft 选举（选 GTID 最新的节点）

1. 所有健康节点 B/C/D/E 任期号 term 自增 1。

2. 每个节点投票给自己，并向其他节点发送 RequestVote RPC。

3. 投票规则：只投给

   任期号更大 + GTID 最新

   的节点。

   • 此时 B/C 拥有最新的 GTID1，D/E 可能还没同步完。
   • B 向 C/D 拉票，C 向 B/E 拉票。

步骤 4：获得多数票，新主诞生

• 假设 B 拿到了 C/D 的投票 → 共 3 票（满足多数派）。
• B 当选新主，立刻向其他节点发送心跳（维持 Leader 身份）。

步骤 5：主从切换（保证数据不丢）

1. 旧主 A 已宕机 → 跳过降级只读步骤。
2. Operator 等待新主 B 追平所有 relay log（确保 GTID1 已执行）。
3. 新主 B 执行 SQL：

STOP REPLICA;
RESET REPLICA ALL;
SET GLOBAL READ_ONLY=OFF;

剩余从库 C/D/E 重新指向新主 B：

CHANGE MASTER TO MASTER_HOST='B';
START REPLICA;

关键结论

新主 B 拥有所有已提交数据 GTID1，切换后集群数据完整，无丢失。

三、极端场景：2 个节点宕机（集群仍可用）

假设主库 A + 从库 E 同时宕机 → 健康节点 B/C/D（3 个，刚好满足多数派）：

1. 集群仍能选出新主（比如 B），正常提供读写服务。
2. 已提交数据 GTID1 存在于 B/C/D → 完全不丢数据。
3. 等 A/E 重启后，会自动同步新主 B 的数据，加入集群。