Incompatible Change: The minimum value for the RedoOverCommitCounter data node configuration parameter has been increased from 0 to 1. RedoOverCommitLimit也已从 0 增加到 1。

在升级之前，您应该检查集群全局配置文件并对为这些参数设置的值进行任何必要的调整。（漏洞#29752703）

添加了DUMP 9988和 DUMP 9989命令。（缺陷号 30520103）

与和选项一起 执行ndb_restore 不会为目标数据库中的任何表创建索引。（缺陷号 30411122）--rebuild-indexes--rewrite-database--exclude-missing-tables

如果事务在从磁盘页面缓冲区获取页面时中止并且磁盘系统过载，事务将无限期挂起。这也可能导致重新启动挂起和节点故障处理失败。（错误#30397083，错误#30360681）

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

数据节点故障并显示错误Another node failed during system restart...发生在部分重启期间。（缺陷号 30368622）

对于已完成的本地检查点，集群日志中报告了错误的字节数。（缺陷号 30274618）

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

备份完成时写入群集日志的摘要事件的数据字节数被截断为 32 位，因此日志记录数与此事件在日志中打印的数据记录数之间存在显着不匹配. （漏洞#29942998）

在每个节点有 10 个线程的 2 节点集群上使用 2 个 LDM 线程可能会导致分区不平衡，这样每个节点上的一个 LDM 线程是零碎片的主要线程。尝试从此集群恢复多线程备份失败，因为一个 LDM 的数据文件仅包含 12 字节的数据文件头，ndb_restore无法读取。在其他情况下也会出现同样的问题，比如在线添加一个空节点后立即进行备份。

发现这个是在 ODirect启用了EOF备份数据文件写入，其大小小于512字节且备份处于该STOPPING状态时出现的。这通常只发生在中止的备份中，但也可能发生在 LDM 没有碎片的成功备份中。我们通过引入额外的检查来解决这个问题，以确保只有当备份实际上包含一个应该导致它中止的错误时才会跳过写入。（缺陷号 29892660）

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

在某些情况下SignalSender，用作ndb_mgmd和 实现的一部分的类会ndbinfo缓冲过多数量的不需要SUB_GCP_COMPLETE_REP和 API_REGCONF信号，从而导致不必要的内存消耗。（漏洞 #29520353）

参考资料：另请参阅：Bug #20075747、Bug #29474136。

每当节点关闭时，都会重新计算最大全局检查点 (GCP) 提交延迟和 GCP 保存超时，以考虑数据节点数量的变化。当阈值降低到先前的值以下时，这可能会导致可行节点的意外关闭。（漏洞#27664092）

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

插入子行的事务可以与删除该子行的父行的事务同时运行。在这种情况下，应该中止其中一个事务，以免产生孤立的子行。

在提交对子行的插入之前，会触发对父行的读取以确认父行存在。类似地，在父行上提交删除之前，执行读取或扫描以确认不存在子行。当插入和删除事务同时运行时，它们的准备和提交操作可以以两个事务都提交的方式进行交互。发生这种情况是因为触发读取是使用LM_CommittedRead 锁执行的（参见 参考资料 NdbOperation::LockMode），锁的强度不足以防止此类错误场景。

通过对两个触发读取使用更强的 LM_SimpleRead锁定模式来解决此问题。使用LM_SimpleReadrather than LM_CommittedReadlocks 确保在涉及并发插入子行和从父行删除的事务的每种可能场景中至少有一个事务中止。（缺陷号 22180583）

同一 SQL 节点上的并发SELECT和 ALTER TABLE语句有时会在等待释放锁时相互阻塞。（错误#17812505，错误#30383887）