MySQL NDB节点组和数据副本如何对应

MySQL NDB 的节点组负责承载一部分分区，同一个分区的多个 fragment replica 放在该组的不同数据节点上。NoOfReplicas 表示每个分区的副本数量，包含主副本，不是主副本之外再增加几个副本。不同组分担不同分区，因此“有两个节点组”不等于“有两份完整数据库”。本文限定 NDB Cluster 8.4。

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

先把整表、分区和副本分开

理解一行数据落在哪里，可以先把三个层次分开：表是逻辑对象，分区是表数据的划分，fragment replica 是分区的一份拷贝。不能把“分区”和“副本”交替使用；前者回答数据怎样拆开，后者回答拆开后的同一份内容保存几份。

可以把它记成两种维度：分区处理不同数据的分布，副本处理相同数据的冗余。下面只用一个假设布局说明这两个维度，没有启动集群，也没有把示例编号当作实际配置。

确认节点组对应的是数据节点

节点组中的成员是数据节点，不是 SQL 节点或管理节点。标准布局下，组数等于数据节点数除以 NoOfReplicas，各组的数据节点数相同。这些定义及分区副本关系来自 MySQL 官方节点与副本说明。

部署已有集群时，应读取真实组归属，不要仅按节点 ID 是否连续推测分组。在具备访问权限的管理环境中，下面的 shell 写法向管理服务执行只读 SHOW：

# 将地址替换为已授权管理服务；只读取配置与节点信息
ndb_mgm --connect-string=mgm.example.internal:1186 --execute="SHOW"

这里的地址是占位示例，不是实际服务入口；如部署要求 TLS，应按现有安全连接配置执行。SHOW 会显示节点类型和数据节点的 Nodegroup 等基本信息。命令含义见 官方管理客户端命令说明。不要因查看归属而追加停止、重启或删除节点组的命令。

同组保存副本，跨组分担分区

假设四个数据节点 A、B、C、D，NoOfReplicas 为 2，形成组甲和组乙。组甲包含 A、B，保存分区 P 的两份拷贝；组乙包含 C、D，保存另一个分区 Q 的两份拷贝。这只展示两个分区的归属，不表示实际表一定只有两个分区。

判断对应关系时要读横向的一行：P 的两份拷贝内容对应同一分区。不能把 A 上的 P 与 C 上的 Q 当作彼此的备用副本。一个节点也可能承载多个分区副本，不能把节点和单个分区一对一绑定。

从查询入口理解数据在哪里

SQL 节点是应用访问 NDB 数据的入口，但增加 SQL 节点并不等于增加分区副本。副本数和节点组成员要从数据节点布局判断。理解查询时，应把“连接到哪一个 SQL 服务”和“目标数据对应哪个分区”分开考虑。

这个区分也能解释为什么两台 SQL 服务可以访问同一个逻辑表，却不能据此推出它们各自保存一份完整 NDB 数据。本文讨论对象归属，不假设所有查询都只触及一个分区，也不把副本角色当作 SQL 节点的主从角色。

故障判断不能只数存活节点

沿用假设布局：若 A 和 C 可用，P、Q 各有一份对应副本；若只剩 C 和 D，则即使仍有两个数据节点，P 的两份副本都不可用。两种情况的存活节点数相同，数据覆盖却不同。这是由示例归属推导出的判断，不是故障演练结果。

因此，故障观察至少要按组归属看覆盖，不能仅看存活节点总数。副本覆盖只是可用性分析的一部分；实际恢复还要考虑节点状态、网络和集群运行条件，不能凭这张关系图保证服务必然可用。

维护记录要保留哪些对应关系

维护清单建议保留“节点 ID、主机、节点组、预期副本数、观察时间”。数据分区的详细布局另外记录，不能只凭 SHOW 的组成员列表就声称已经获得每张表的完整分区映射。查看归属与改变归属是两类工作，本文不提供变更操作。

同组副本应避免共用单一故障来源；仅仅运行多个进程，不代表已经消除同一主机故障的影响。这是从冗余目标出发的部署考虑，具体放置仍应结合真实机器和基础设施设计。

NoOfReplicas 为 2 是一主加两个备吗？

不是，是每个分区总共两份副本。讨论容量或冗余时都应使用总副本数，避免多算一份。

两个节点组中的节点能相互替代吗？

不能仅凭节点数量这样判断。示例中组乙保存 Q 的副本，不能代替组甲缺失的 P。

副本可以代替备份吗？

两者目标不同。副本对应当前数据的冗余，独立备份用于恢复需求；维护计划不应因为存在副本就省略备份安排。

用“分区归组、同组多副本、节点承载副本”读布局，比记一张固定编号图更可靠。先明确实际组成员，再谈数据覆盖与故障风险，才不会把节点组误当成完整库的复制单位。