MySQL NDB Cluster数据节点不同步及查询结果不一致故障求助

问题场景回顾 #

你的SQL节点触发too many connection error故障，通过ndb_mgm查看集群状态发现数据节点2已关闭；重启数据节点2和SQL节点后，数据节点2卡在starting状态长达2小时才完成启动，随后执行select count(*) from summantions时，首次返回约1.07亿行，再次执行却返回约9000万行，结果出现明显差异。

核心原因拆解 #

1. 数据节点启动时的分片同步未完成
   NDB集群的数据节点重启后，会从其他存活节点同步自己负责的分片数据。如果数据节点2离线时间久、集群数据量又大，同步过程会非常耗时（你的2小时启动时间就是典型表现）。首次执行count(*)时，数据节点2可能还处于部分同步状态，此时查询会拉取到未完全校验的临时数据，导致计数偏大；等同步彻底完成后，再次查询就会得到集群一致的准确计数。

2. too many connections的本质原因
   这个错误要么是SQL节点的max_connections设置超过了NDB数据节点的连接上限，要么是数据节点的MaxNoOfConnections配置不足以支撑业务连接量，甚至可能是应用存在连接泄漏（比如未释放的长连接、连接池配置不合理）。

分步解决方案 #

1. 先确认集群状态是否完全正常 #

首先用ndb_mgm工具检查所有数据节点的状态，确保没有节点处于同步或恢复中：

ndb_mgm -e "show"

只有当所有数据节点都显示为started状态时，再执行查询才会得到准确结果。

2. 校验数据一致性 #

为了彻底确认summantions表的数据是否一致，可以做这两步：

• 逐个检查数据节点上的分片行数：

  # 登录到每个数据节点主机执行，替换你的数据库名
  ndb_selectcount -d your_db_name summantions
  

  把所有节点的计数相加，应该等于最终的count(*)结果。
• 查看表的分片分布与状态：

  ndb_desc -d your_db_name summantions -p
  

  检查是否存在损坏或异常的分片。

3. 根治too many connections问题 #

• 调整SQL节点连接数：修改MySQL配置文件（my.cnf/my.ini）中的max_connections，确保其不超过NDB数据节点的MaxNoOfConnections配置值。
• 调高数据节点连接上限：修改集群配置文件config.ini中的MaxNoOfConnections参数（默认150），根据业务需求适当调高，之后重启所有数据节点生效。
• 排查连接泄漏：检查应用程序的连接池配置，比如是否设置了合理的连接超时、是否存在未关闭的连接实例。

4. 优化数据节点启动速度 #

2小时的启动时间明显过长，可从这几点优化：

• 确保数据节点之间使用高速内网（比如万兆网卡），减少同步时的网络瓶颈。
• 如果你的NDB版本支持，开启增量同步功能，避免每次重启都全量同步数据。
• 定期清理过期数据，降低数据节点的存储与同步压力。

极端情况处理 #

如果多次查询结果仍然不一致，可能是表存在数据损坏，可尝试：

REPAIR TABLE summantions;

或者使用NDB官方的修复工具：

ndb_restore -d your_db_name -n 2 --restore-data

（-n 2指定修复数据节点2，根据实际节点ID调整）

内容的提问来源于stack exchange，提问作者RADU