ndb_restore现在报告具体的NDB当无法从备份中加载表描述符时，错误编号和消息.ctl文件。当试图将一个更新版本的NDB集群软件的备份恢复到运行较早版本的集群时，可能会发生这种情况——例如，当备份包含一个使用了版本未知字符集的表时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.6的集群中，从NDB 7.4的备份中更改分区。通过确保升级代码处理，可以修复这个问题PartitionBalance控件提供一个有效的表规范NDB字典。(错误# 29955656)

NDB索引统计信息是基于有序索引的一个片段的拓扑结构计算的;在任何特定索引中选择的片段都是在索引创建时决定的，即当索引最初创建时，以及当节点或系统重新启动时，在本地重新创建了索引。这种计算在一定程度上是基于索引中的片段数量的，当表被重新组织时，这些片段的数量可能会改变。这意味着，下次节点重新启动时，这个节点可能会选择一个不同的片段，因此没有片段、一个片段或两个片段被用于生成索引统计信息，从而导致错误分析表．

解决这个问题的方法是修改在线表重组，立即重新计算选中的片段，这样所有节点在任何后续重启前后都是对齐的。(错误# 29534647)

日志含义当数据节点已经启动但还没有选出总裁时，管理服务器在重启过程中收到一个已使用的节点ID错误，导致过多的重试和日志记录。这是通过引入一个新的错误1705来修复的还没有准备好分配连接对于这种情况。

在重新启动期间，当数据节点尚未完成节点故障处理时，一个虚假的事件解释分配nodeID失败错误返回。通过添加一个检查来检测不完整的节点启动并返回错误1703，可以修复这个问题节点故障处理未完成代替。

作为这个修复的一部分，重试的频率已经降低未准备分配nodeID为了测试目的，已经添加了一个错误插入来模拟缓慢重启，并且日志消息已经被改写，表明相关的节点ID分配错误是轻微的，而且只是暂时的。(错误# 27484514)