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

MySQL NDB ClusterJ： 如果 ClusterJ 被部署为多模块 Web 应用程序的单独模块，当应用程序尝试创建域对象的新实例时， java.lang.IllegalArgumentException: non-public interface is not defined by the given loader会抛出异常。这是因为 ClusterJ 总是试图创建一个代理类，从中可以实例化领域对象，而代理类是领域接口和受保护对象的实现DomainTypeHandlerImpl::Finalizable 界面。这两个接口的类加载器在案例中是不同的，因为它们属于运行在 web 服务器上的不同模块，所以当 ClusterJ 试图使用域对象接口的类加载器创建代理类时，会抛出上述异常. 此修复使Finalization接口公开，以便 Web 应用程序的类加载器能够访问它，即使它属于与域接口不同的模块。（错误号 29895213）

MySQL NDB ClusterJ： 在重新连接到 NDB Cluster 后，ClusterJ 有时会因分段错误而失败。这是由于 ClusterJ 重用了旧连接中的旧数据库元数据对象。通过修复，这些对象在重新连接到集群之前被丢弃。（漏洞#29891983）

执行全局模式锁 (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）