重要更改： 当使用与原始集群中的数据节点 ID 不同的数据节点 ID 恢复到集群时， ndb_restore 尝试打开与节点 ID 0 对应的文件。为了防止这种情况发生，--nodeid 和--backupid 选项——它们都没有默认值——是现在在调用 ndb_restore时明确需要两者。（漏洞#28813708）

NDB Disk Data： 当一个日志文件组有超过 18 个撤销日志时，无法重新启动集群。（漏洞#251155785）

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

当本地检查点 (LCP) 在除一个以外的所有数据节点上完成时，并且该节点失败时，NDB没有继续完成 LCP 所需的步骤。这导致了以下问题：

无法启动新的 LCP。

重做和撤消日志未被修剪，因此变得过大，导致从磁盘恢复的时间增加。这导致写入服务失败，最终导致重做日志头部遇到尾部时集群关闭。这限制了集群的正常运行时间。

节点重启不再可能，因为数据节点重启需要节点的状态在磁盘上持久化，然后才能在加入集群时提供冗余。对于具有两个数据节点和两个分片副本的集群，这意味着需要重新启动整个集群（系统重启）才能解决此问题（对于具有两个分片副本和四个或更多数据节点的集群来说，这不是必需的） . （错误#28728485，错误#28698831）

参考资料：另请参阅：错误 #11757421。

在索引长度超过支持的最大长度ANALYZE TABLE的 表上 运行会导致数据节点失败。NDB（漏洞#28714864）

在某些情况下，节点可能会在初始重启期间挂起。（缺陷号 28698831）

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

ndb_config 的输出现在显示 和 数据节点参数的配置更改需要系统初始重启 ( )。（漏洞#28494286）--configinfo --xml --query-allThreadConfigMaxNoOfExecutionThreadsrestart="system" initial="true"

在某些情况下，执行会导致 SQL 节点重新启动。（漏洞#27613173）SELECT * FROM INFORMATION_SCHEMA.TABLES

当包含BLOB列的表被删除然后使用不同数量的 BLOB列重新创建时，当未执行相应事件的预期清理时，在涉及通信错误的某些错误情况下，用于监视表更改的事件定义可能会变得不一致。特别是，当新版本的表 BLOB比原来的表有更多的列时，一些事件可能会丢失。（漏洞#27072756）

在非常高的负载下运行具有 4 个或更多数据节点的集群时，数据节点有时会失败并显示错误 899 Rowid already allocated。（缺陷号 25960230）

启动时，数据节点复制元数据，而本地检查点更新元数据。为避免任何冲突，在复制元数据时暂停任何正在进行的 LCP 活动。当本地检查点在给定节点上暂停时出现问题，并且另一个节点也在重新启动检查该节点上的完整 LCP；检查实际上导致 LCP 在元数据复制完成之前完成，因此过早地结束了暂停。现在在这种情况下，LCP 完成检查会等待完成暂停的 LCP，直到元数据复制完成并且暂停按预期结束，在它开始的 LCP 内。（漏洞 #24827685）

mysqld与集群 的异步断开导致任何后续启动 NDB API 事务的尝试失败。如果这发生在批量删除操作期间，名为 的 SQL 层 HA::end_bulk_delete()，其实现ha_ndbcluster假定事务已启动，如果不是这种情况，则可能会失败。通过在引用此方法之前检查是否设置了此方法使用的事务指针来解决此问题。（缺陷号 20116393）

NdbScanFilter并不总是 NULL根据 SQL 标准处理，这可能导致发送不合格的行以被 MySQL 服务器过滤（否则不需要）。（缺陷 #92407，缺陷 #28643463）

参考资料：另请参阅：Bug #93977、Bug #29231709。

NDB尝试在大于 ( >) 和小于 ( <) 与 ENUM列值的比较中使用条件下推，但这可能会导致结果中省略行。现在这样的比较不再被推倒了。相等 ( =) 和不等 ( <>/ !=) 与 ENUM值的比较不受此更改的影响，包括这些比较的条件仍然可以下推。（缺陷 #92321，缺陷 #28610217）