MySQL NDB仲裁优先级怎么配置

在MySQL NDB集群中配置仲裁优先级，核心是通过调整对应节点的仲裁权重参数，指定集群选举仲裁节点时的偏好顺序，减少节点故障后集群不可用的概率。

调整节点对应的`ArbitrationRank`参数即可完成仲裁优先级配置，配置完成后滚动重启对应NDB节点生效即可。

如果 NDB 集群发生网络分区，数据节点需要仲裁者决定哪一侧继续工作。配置仲裁优先级时，核心参数是 ArbitrationRank：0 表示该节点不参加仲裁，1 表示高优先级，2 表示低优先级。通常让管理节点优先，SQL/API 节点不参与或只作为备用候选。

官方文档：https://dev.mysql.com/doc/refman/8.4/en/mysql-cluster.html

本文限定 MySQL NDB Cluster 8.4 的 config.ini，不把普通 MySQL InnoDB 的高可用参数混进来。下面的配置片段是说明用示例，不代表某个现有集群的实测结果。

先确认问题确实属于 NDB 仲裁

排查现场常见的误区是把“谁应该成为仲裁者”和“哪台机器性能更好”画上等号。NDB 的仲裁候选主要由管理节点和 SQL/API 节点提供，ArbitrationRank 只表达候选资格与优先级，不是 CPU、内存或网络带宽评分。

在 NDB 8.4 中，管理节点默认更适合作为高优先级仲裁者，SQL 节点默认不参与。若业务确实需要让 SQL/API 节点承担备用仲裁，再把它设成低优先级候选；不要把所有节点都设成同一个“最高优先级”，否则配置失去清晰的主次关系。

ArbitrationRank 的 0、1、2 到底代表什么

这个参数可以写在管理节点和 SQL/API 节点对应的配置段。它表达的是静态候选关系：1 比 2 优先，但最终是否能够被数据节点看到，还取决于节点连接状态和集群当前视图。

把主仲裁和备用仲裁写进配置段

下面给出一个“管理节点优先、SQL 节点不参与、API 节点作为低优先级备用”的表达方式。真实环境中的 NodeId、节点数量和分组要按自己的集群文件调整。

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

[mysqld]
NodeId=3
ArbitrationRank=0
# SQL 节点不参与仲裁，避免把业务连接节点当成首选。

[api]
NodeId=4
ArbitrationRank=2
# 只有高优先级仲裁节点不可用时，才把该 API 节点作为低优先级候选。

如果某个 SQL/API 节点没有承担备用职责，就保持为 0。真正需要备用候选时，也应先确认它与数据节点之间的网络路径稳定，不能只因为机器空闲就把它设为 2。

别忘了 Arbitration 的覆盖关系

只看 ArbitrationRank 还不够。NDB 还支持在 [ndbd default] 中设置 Arbitration。如果把它设成 Disabled，效果相当于让管理节点和 API 节点都不参与仲裁，此时单个节点上的 ArbitrationRank 设置会被忽略；WaitExternal 则表示把仲裁等待交给外部集群管理程序。

[ndbd default]
# 默认策略才会按管理节点和 SQL/API 节点的 ArbitrationRank 选择。
Arbitration=Default

# 只有明确不使用 NDB 内部仲裁时才考虑 Disabled；它会覆盖 ArbitrationRank。
# Arbitration=Disabled

修改管理节点或 SQL/API 节点的 ArbitrationRank 后，需要按 NDB 的节点重启要求安排滚动重启。不要把“配置文件已经改好”当成“所有数据节点已经采用新视图”，尤其不要在生产故障窗口里临时同时重启全部节点。

用 ndbinfo 区分配置意图和实际仲裁视图

配置文件只能说明候选优先级，观察数据节点看到的仲裁者时，可以读取 ndbinfo.membership。下面的查询只读取仲裁相关列；输出中的 arbitrator 是节点当前视图，connected_rank1_arbs 和 connected_rank2_arbs 可帮助判断各优先级候选的连接情况。

-- 只读取仲裁视图，不修改 NDB 集群配置或数据。
SELECT node_id,
       arbitrator,
       arb_connected,
       connected_rank1_arbs,
       connected_rank2_arbs
FROM ndbinfo.membership;

如果不同数据节点长期显示不同的仲裁者，先检查节点连通性、配置是否被 Arbitration 覆盖，以及是否已经完成计划内的滚动重启。不要只凭一台 SQL 节点的配置文件就宣布仲裁优先级已经生效。

常见误区与速查

• 把 2 当成“第二台机器”：它表示低优先级，不是固定的物理编号。
• 只给 SQL 节点设 1：这样会改变候选主次，除非有明确的部署理由，否则优先让管理节点承担该角色。
• 忽略 Arbitration：Disabled 或 WaitExternal 会改变 ArbitrationRank 的作用范围。
• 只看文件不看视图：用 ndbinfo.membership 观察各数据节点是否看到一致的仲裁信息。

ArbitrationRank=0 是不是关闭整个集群仲裁？不是。它只让当前管理节点或 SQL/API 节点不成为仲裁者；要关闭 NDB 内部仲裁，还要按官方规则在相关节点上统一处理或使用 Arbitration 策略。

ArbitrationRank=1 和 2 能不能同时写在一台节点上？不能把它当成多个候选级别叠加。一个节点应有一个明确取值，集群再根据可用候选和优先级选择仲裁者。

配置改完为什么查询结果没变？先确认修改的是实际使用的 config.ini，再确认对应节点已按要求重启，并从多个数据节点的视图交叉观察。

记住一条即可：0 不参与，1 主优先，2 备用；Arbitration 可能覆盖这套节点级意图，最终判断要回到数据节点的仲裁视图。