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

ndb_mgmDUMP 1000客户端中 的输出已扩展为提供有关总数据页使用情况的信息。（漏洞#29841454）

参考资料：另请参阅：Bug #29929996。

NDB 磁盘数据： 当数据节点在创建和填充 NDB磁盘上有列的表后失败时，但在执行本地检查点之前，可能会丢失表空间中的行数据。（漏洞 #29506869）

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）

数据节点启动后，其配置的 95% DataMemory应可用于正常数据，5% 可用于紧急情况。在节点启动过程中，其配置DataMemory的所有数据都可用于数据，以最大程度地减少由于某些动态内存结构为相同数据使用更多页面而导致数据内存耗尽而导致节点数据恢复失败的风险。节点已停止。例如，哈希表在重新启动期间的增长与之前不同，因为插入表的顺序与历史顺序不同。

当检查使用的数据内存加上备用数据内存不超过设置的值时，此错误报告中出现的问题DataMemory在备用内存保留点失败。当保留备用页面时，数据节点的状态从开始过渡到开始时发生这种情况。在计算了用于备用内存的保留页数，然后计算了为此使用的共享页数（即来自共享全局内存的页数）后，已分配的保留页数未被考虑在内。（缺陷号 30205182）

参考资料：另请参阅：Bug #29616383。

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

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

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

启动时，数据节点的本地 sysfile 在第一个完成的本地检查点和启动阶段 50 之间没有更新。（缺陷 #30086352）

在BACKUP块中，假设第一个记录 c_backups是本地检查点记录，但情况并非总是如此。现在NDB循环遍历中的记录c_backups以查找（正确的）LCP 记录。（缺陷号 30080194）

在 master 的节点接管期间，有可能在 state 结束，LCP_STATUS_IDLE而其余数据节点将其状态报告为 LCP_TAB_SAVED. 这导致节点在尝试处理 LCP_COMPLETE_REP信号接收时出现故障，因为在空闲时这不是预期的。现在在这种情况下，本地检查点处理以确保该节点以正确状态 ( LCP_TAB_SAVED) 完成的方式完成。（缺陷号 30032863）

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

在 NDB Cluster 升级过程中，当一半数据节点运行 NDB 7.6 而其余数据节点运行 NDB 8.0 时，尝试关闭那些运行 NDB 7.6 的节点会导致一个节点出现故障并出现错误CHECK FAILEDNODEPTR.P-> DBLQHFAI。（错误#29912988，错误#30141203）

执行本地检查点 (LCP) 时，表的架构版本间歇性读取为 0，这导致 NDBLCP 处理将该表视为正在删除。当表处于该状态时，这可能会影响通过ndb_restore离线重建索引。TABLE_READ_ONLY现在读取架构版本 ( getCreateSchemaVersion()) 的函数不再在表为只读时更改它。（缺陷号 29910397）

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

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

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

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

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

选择事务协调器的过程会检查 “实时”数据节点，但不一定检查那些实际可用的节点。（漏洞 #27160203）