ndb_restoreNDB现在在无法从备份 .ctl文件报告特定的 当尝试将从较新版本的 NDB Cluster 软件获取的备份还原到运行较早版本的集群时，可能会发生这种情况 - 例如，当备份包含使用字符集的表时，该字符集对于 正在使用的ndb_restore版本是未知的恢复它。（缺陷号 30184265）

执行全局模式锁 (GSL) 时， 在尝试获取表对象引用时NDB使用单个 Ndb_table_guard对象连续退出；在第一次尝试失败后，这是不可能成功的，因为Ndb_table_guard假设底层对象指针只在初始化时确定一次，之前检索到的指针随后从缓存的引用中返回。

这导致无限等待获取 GSL，导致 binlog 注入器线程挂起，因此mysqld 认为所有NDB表都是只读的。为避免此问题，现在为每次此类重试NDB使用一个新实例。Ndb_table_guard（缺陷号 30120858）

参考：这个问题是 Bug #30086352 的回归。

将MAX_ROWS用于将分区从 NDB 7.4 制作的备份更改为运行 NDB 7.6 的集群的表无法正常工作。这是通过确保升级代码处理 为字典PartitionBalance提供有效的表规范来解决的。NDB（漏洞#29955656）

NDB索引统计信息是根据有序索引的一个片段的拓扑结构计算的；在任何特定索引中选择的片段是在索引创建时决定的，无论是在最初创建索引时，还是在节点或系统重启在本地重新创建索引时。此计算部分基于索引中的片段数，重组表时片段数可能会发生变化。这意味着，下次重启该节点时，该节点可能会选择不同的分片，从而不使用分片、使用一个分片或使用两个分片来生成索引统计信息，从而导致ANALYZE TABLE.

这个问题通过修改在线表重组来立即重新计算选择的片段来解决，这样所有节点在任何后续重启之前和之后都是对齐的。（漏洞#29534647）

在数据节点已经启动但尚未选出总统的重启期间，管理服务器收到一个 节点 ID 已在使用错误，这导致过多的重试和日志记录。这是通过引入新错误 1705 Not ready for connection allocation yet for this case 来解决的。

在数据节点尚未完成节点故障处理的重新启动期间，返回虚假的Failed to allocate nodeID错误。这是通过添加检查来检测未完成的节点启动并返回错误 1703节点故障处理未完成 来解决的。

作为此修复的一部分，针对未准备好分配节点 ID错误 的重试频率已降低，已添加错误插入以模拟缓慢重启以用于测试目的，并且日志消息已改写以指示相关节点 ID 分配错误很小，而且只是暂时的。（漏洞#27484514）