MySQL NDB仲裁节点怎样参与网络分区判断

MySQL NDB 的仲裁节点不是“投票服务器”或 SQL 查询入口，它只在数据节点可能被网络分成两个互相看不见的集合时，帮助集群决定哪一边继续运行。判断逻辑可以概括为：数据节点先发现分区风险，候选仲裁者接收仲裁请求，先联系到仲裁者的一组节点获得继续运行的许可，另一组被要求停止。这样做的目标是避免 split-brain，而不是替 SQL 节点提供应用层自动切换。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/faqs-mysql-cluster.html

仲裁节点先判断什么风险

如果一个或多个数据节点失效，剩余节点未必还能互相通信。假设两个节点集合都认为自己代表完整集群，它们就可能同时对外提供服务，这正是 NDB 要避免的 split-brain。官方 FAQ 给出的边界是：当至少一个节点组的全部数据节点仍然存活时，单个子集不能独立组成可工作的集群，网络分区通常不是问题；当没有任何一个节点组完整存活时，分区才可能需要仲裁。

因此，看到某个数据节点掉线时不要马上修改仲裁参数。先区分“节点进程失败”和“节点之间互相不可见”。仲裁节点不保存业务数据，也不替代数据节点组的副本判断，它只为竞争中的集合提供一个外部决策点。

ArbitrationRank 怎样决定候选顺序

NDB 8.4 中，管理节点和 SQL/API 节点都可以成为仲裁者。常见设计是把独立机器上的管理节点设为高优先级，把 SQL 节点保持为不参与；只有确实需要备用候选时，才给某个 SQL/API 节点设置低优先级。配置变化属于节点重启范围，不能把它当成动态会话参数。

[ndb_mgmd default]
# 管理节点作为首选仲裁候选，优先级高
ArbitrationRank=1

[mysqld]
# SQL 节点默认不承担仲裁职责
ArbitrationRank=0

[api]
# 只有规划为备用仲裁者时才使用低优先级
ArbitrationRank=2

还要留意全局 Arbitration 设置：如果在 [ndbd default] 中指定它，文档说明该设置会使各节点的 ArbitrationRank 被忽略。也就是说，看到 rank 配置并不等于它正在生效，必须同时检查全局仲裁方案。

网络分区时仲裁怎样做出取舍

分区发生后，两个集合都会尝试联系大家认定的仲裁节点。仲裁者接受第一个联系到它的集合，并让剩余集合关闭；日志中可以看到“需要仲裁”“收到正回复”或“收到负回复”等结果。这个“先联系到”不是业务优先级，也不是按 SQL 请求量排序，而是集群通信和仲裁票据共同形成的决策过程。

排查日志时，把下面三类结果分开看：Arbitration succeeded 表示请求得到肯定回复；Arbitration failed 表示仲裁者拒绝该集合；no arbitrator available 或 no arbitrator configured 则说明候选节点不可达或没有有效配置。最后两类应回到网络连通性、rank 和仲裁总开关，而不是反复重启应用。

用 ndbinfo 确认所有节点看到同一个仲裁者

仲裁是否“配置正确”，不能只看某台管理机的配置文件。可以从 SQL 节点查询 NDB 信息表，比较各数据节点的视图：

-- 查看每个数据节点看到的仲裁者和状态
SELECT node_id, arbitrator, arb_ticket, arb_connected, arb_state
FROM ndbinfo.arbitrator_validity_detail;

-- 汇总仲裁者是否得到数据节点的一致认可
SELECT arbitrator, arb_ticket, arb_connected, consensus_count
FROM ndbinfo.arbitrator_validity_summary;

-- 查看 president、successor 以及 rank 1/2 候选的连接状态
SELECT node_id, president, successor, arbitrator,
       arb_ticket, arb_state, arb_connected,
       connected_rank1_arbs, connected_rank2_arbs
FROM ndbinfo.membership;

正常情况下，arbitrator_validity_detail 中各行应显示一致的 arbitrator、arb_ticket 和 arb_state；汇总表在稳定期间通常只有一行。如果长时间出现多行，往往意味着节点没有连接到同一个仲裁者，或虽然连通却没有形成一致视图。arb_connected=No 也不能被忽略，它说明当前数据节点到所示仲裁者的连接并未建立。

这套检查清单能回答“仲裁节点怎样参与网络分区判断”：它不直接决定业务数据谁更新，而是在集群集合之间提供单一裁决点；真正的配置决策由 ArbitrationRank 和 Arbitration 控制，运行时证据则来自 ndbinfo 表和集群日志。

常见问题

仲裁节点是不是必须是数据节点

不是。管理节点和 API/SQL 节点都可以成为仲裁者，数据节点本身不是优先选择。通常把管理节点放在与数据节点不同的机器上，才能在一个数据节点失效时继续提供仲裁服务。

ArbitrationRank 设置成 2 就一定会成为备用仲裁者吗

不一定。它只是低优先级候选，还要满足仲裁总开关未禁用、节点可达且高优先级候选不可用等条件。若 Arbitration 被显式设置，rank 还可能被忽略。

仲裁能否替代 SQL 节点自动故障转移

不能。仲裁解决的是数据节点集合的生存裁决；SQL 节点之间的连接切换仍要由应用或外部架构处理。