MySQL NDB配置文件修改后哪些节点需要重启

MySQL NDB Cluster 修改配置后，是否需要重启整簇，关键不在“改了配置文件”这句话，而在于改的是哪一个文件。config.ini 是管理节点读取并分发的全局配置，通常要先处理 ndb_mgmd，再让数据节点和 SQL/API 节点逐个载入新配置；某台主机上的 my.cnf 则只影响实际读取它的本地进程。

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

下面按 MySQL NDB Cluster 8.4 文档中的节点职责说明重启边界。生产环境仍应先确认具体参数的“restart type”，不要把示例命令当成未经评估的变更操作。

先分清两类配置文件：config.ini 和 my.cnf

这是最容易混淆的架构边界。config.ini 通常只由 NDB 管理服务器读取，里面描述数据节点、节点连接以及集群级参数。管理服务器还会缓存这份配置，因此仅仅改完文件并不会让已经运行的进程自动获得新值。

my.cnf 是每个节点主机上的本地配置入口。数据节点和 SQL 节点需要在其中配置连接管理节点的信息；SQL 节点还可能通过它启用 NDBCLUSTER。因此，修改某一台主机的 my.cnf，首先要判断该文件被 ndbd、ndbmtd 还是 mysqld 使用，而不是笼统地重启所有节点。

# config.ini：由管理节点读取的集群级配置示意
[ndbd default]
# 该段描述数据节点共用的副本数
NoOfReplicas=2

# my.cnf：某台数据节点或 SQL 节点主机上的本地入口
[mysqld]
# 让 mysqld 使用 NDB 存储引擎
ndbcluster

[mysql_cluster]
# 告诉本地进程管理节点的位置
ndb-connectstring=198.51.100.10

config.ini 改动：先处理管理节点，再处理受影响节点

修改 config.ini 时，管理节点是第一责任点。MySQL 文档给出的通用滚动重启模型是：停止管理节点，重新配置并启动；然后逐个停止、重新配置并启动数据节点；最后逐个处理 SQL 节点。多管理节点场景还要特别注意它们可能互相复用配置数据。

多管理节点时，稳妥的配置关系是：先停止全部 ndb_mgmd，把每台机器上的 config.ini 同步为同一版本，再启动一个管理节点使用 --reload 或 --initial 读取新文件，随后启动其余管理节点。若首个管理节点使用了 --initial，其余管理节点也要按文档要求使用对应方式。

# 以下是维护窗口中的命令示意，不代表本文已在真实集群执行
# 先停止全部管理节点，避免某个存活节点继续提供旧配置
ndb_mgm -e "SHUTDOWN"

# 首个管理节点重新读取 config.ini；--reload 保留旧缓存但不再使用
ndb_mgmd --reload

# 若需要清理并重新建立配置缓存，才考虑 --initial
ndb_mgmd --initial

--reload 与 --initial 的取舍不能只看“哪个更强”。前者比较缓存和文件差异，后者删除既有缓存并重新建立；如果只是普通配置更新，先按参数文档选择重载方式，避免把清理缓存当成万能修复手段。

数据节点并不是都用同一种重启方式

管理节点载入新配置后，数据节点仍需要逐个让配置生效。部分数据节点参数可以在管理客户端中对每个节点发出 RESTART；另一些参数要求先用管理客户端的 STOP 完整停止，再从系统 shell 启动 ndbd 或 ndbmtd。最终方式由对应参数的官方说明决定。

这也是“改了配置却看不到效果”的常见原因：管理节点已经生成了新配置缓存，但某个数据节点仍在使用旧进程状态。不要只重启一个任意数据节点来碰运气，应按节点清单逐个覆盖，并保留当前节点的恢复与冗余策略。

# 进入 NDB 管理客户端，按节点 ID 选择维护对象
ndb_mgm

# 对可在线重新载入的参数，使用节点级 RESTART
ndb_mgm> 3 RESTART

# 对要求完整停止的参数，先 STOP；再由系统启动 ndbmtd
ndb_mgm> 3 STOP
# 这里的启动参数必须以该节点实际部署文件为准
ndbmtd --ndb-nodeid=3

my.cnf 改动：只重启真正读取它的本地进程

如果修改的是某台数据节点主机的 my.cnf，通常只需要让该主机上的 ndbd 或 ndbmtd 重新启动；如果修改的是 SQL 节点的 [mysqld] 或 [mysql_cluster]，则需要让该主机上的 mysqld 重新读取文件。若多台主机的文件都被改动，就要把它们分别列入变更清单。

不要把 config.ini 和 my.cnf 混为一个“集群配置”。前者的变化会牵涉管理节点分发和受影响的集群节点；后者的变化首先是本地进程启动参数变化，是否需要扩展到其他节点取决于你是否也同步改了其他主机。

# 仅修改 SQL 节点本地 my.cnf 后的重启示意
# 先保存旧文件，便于人工回退到上一个已知版本
cp /etc/my.cnf /etc/my.cnf.before-change

# 只让读取该文件的 mysqld 重新加载启动参数
systemctl restart mysqld

# 不要把该命令误写成对所有 ndbd 节点的批量重启

用一张重启清单判断是否真的完成

可以把变更按“文件—进程—节点”三列登记。改 config.ini 时至少检查全部管理节点、受影响的数据节点以及需要重新读取本地参数的 SQL/API 节点；改单台 my.cnf 时只把使用该文件的本地进程列入范围。

对于配置滚动重启，MySQL 文档还提供了 ndbinfo.nodes 表中的 config_generation 作为数据节点是否载入新配置的核对线索。它适合做运维收尾记录，但不能替代参数文档对 RESTART 或完整停止的要求。

-- 只读核对示意：查看数据节点的配置代际
-- 该查询用于运维记录，不改变集群状态
SELECT node_id, config_generation
FROM ndbinfo.nodes
ORDER BY node_id;

最后给出一个简短判断清单：

• 改 config.ini：先处理全部管理节点，再按参数要求滚动处理数据节点，最后处理 SQL/API 节点。
• 改数据节点主机的 my.cnf：重启实际读取它的 ndbd 或 ndbmtd。
• 改 SQL 节点的 my.cnf：重启对应 mysqld；多台主机改动就逐台处理。
• 拿不准时：回到对应参数的官方说明，确认是 RESTART、STOP 后启动，还是 SQL 进程重启。

相关问题

只修改 config.ini 后，管理节点不重启可以吗？

通常不可以。NDB 管理节点会缓存全局配置，文件变化需要通过文档规定的重载或初始启动方式让管理节点重新读取。

所有数据节点都必须同时停机吗？

不一定。滚动重启的目的就是逐个处理节点以保持集群可用，但具体参数可能要求完整停止，必须结合副本、节点状态和参数文档安排顺序。

为什么重启了管理节点，SQL 节点仍像使用旧配置？

管理节点重新载入全局配置，不等于 SQL 节点已经重新读取自己的 my.cnf。若变化属于 SQL 节点本地选项，还要单独重启对应的 mysqld。