NDB Cluster API：Ndb当同时创建和删除对象 时，可能会发生事务 ID 的重用 作为此修复的一部分，NDB API 方法 lock_ndb_objects() 和 unlock_ndb_objects 现在声明为const. （漏洞 #23709232）

NDB Cluster API： 当管理服务器在运行持续监视事件的 MGM API 应用程序时重新启动时，后续事件不会报告给应用程序，无限期返回超时而不是错误。

发生这种情况是因为事件侦听器的套接字在重新启动mgmd时未关闭。这是通过确保在管理服务器关闭时关闭事件侦听器套接字来解决的，这会导致应用程序使用诸如 ndb_logevent_get_next()在重新启动后收到读取错误之类的功能。（漏洞#19474782）

传递不存在的节点 ID 会 CREATE NODEGROUP导致随机数据节点故障。（缺陷号 23748958）

DROP TABLE随后是节点关闭和随后的主节点接管——并且在接管之前包含的本地检查点尚未完成——导致 LCP 被忽略，在某些情况下，数据节点出现故障。（漏洞 #23735996）

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

删除了一个无效断言，其效果是在主事务中止后释放 API 连接记录时关闭所有级联子扫描。断言是无效的，因为在这种情况下关闭扫描在设计上与主事务异步，这意味着在主事务关闭后子扫描可能需要一些时间才能关闭。（缺陷号 23709284）

在代码库中发现并修复了许多潜在的缓冲区溢出问题NDB。（漏洞 #23152979）

SIGNAL_DROPPED_REP为响应长消息缓冲区耗尽而调用 的处理程序在SPJ内核块中定义，但实际上并未使用。这意味着 SimulatedBlock在这种情况下使用默认处理程序代替，关闭数据节点。（缺陷号 23048816）

参考资料：另请参阅：Bug #23251145、Bug #23251423。

当一个数据节点在系统重启期间没有足够的重做缓冲区时，它不会参与重启，直到其他节点已经启动。在此之后，它从其节点组中已经启动的节点执行其片段的接管；在此期间，集群已经在运行并且可以进行用户活动，包括 DML 和 DDL 操作。

在系统重启期间，表创建在DIH内核块中的处理方式与正常情况不同，因为这种创建实际上包括从主节点上的磁盘重新加载表定义数据。因此，DIH 假设在所有节点重新启动之前发生的任何表创建都必须与重新启动相关，因此始终在主节点上。但是，在接管期间，由于用户活动，可能会在非主节点上创建表；发生这种情况时，集群会强制关闭。

现在在系统重启期间进行额外检查以检测在这种情况下执行节点是否是主节点，并使用该信息来确定表创建是适当重启的一部分，还是在后续接管期间发生。（缺陷号 23028418）

ndb_restoreMAX_ROWS为在进行备份之前未设置的表设置 （漏洞 #22904640）

每当将数据节点添加到集群或从集群中删除时，NDB内核的事件 API 都会使用SUB_GCP_COMPLETE_REP 带有ADD(add) 标志或 SUB(drop) 标志集的信号以及要添加或删除的节点数来通知此情况；这允许为每个不完整的桶NDB保持正确的未决信号计数 。SUB_GCP_COMPLETE_REP除了处理与添加或删除相关联的时期的桶之外，它还必须补偿与以后的时期相关的任何后来的不完整的桶。尽管有可能不按顺序完成这些桶，但没有对这些桶进行处理，导致活动接待出现停滞。

此修复程序添加了对此类无序存储桶完成的检测和处理。（缺陷号 20402364）

参考资料：另请参阅：Bug #82424、Bug #24399450。

当从包含具有外键的表的数据库中恢复备份时，ndb_restore禁用数据的外键，但不禁用日志。（漏洞 #83155，漏洞 #24736950）

c_exec表中列 显示的计数ndbinfo.threadstat不完整。（漏洞 #82635，漏洞 #24482218）

内部函数 ndbcluster_binlog_wait()提供了一种方法来确保来自给定线程的所有事件都到达二进制日志中，SHOW BINLOG EVENTS在重置二进制日志时使用。此函数等待注入器条件，而处理的最新全局纪元NDB比本会话中最后提交的纪元更新，这意味着每当二进制日志线程完成并更新新的最新全局纪元时，必须发出此条件信号。检查代码显示缺少此条件信号，并且客户端线程不会在新的最新全局纪元完成（~100 毫秒）时被唤醒，而是等待最大超时（1 秒）。

此修复添加了缺少的注入器条件信号，同时还将其更改为条件广播以确保所有客户端线程都收到警报。（缺陷 #82630，缺陷 #24481551）

在节点重启期间，可以使用从本地检查点 (LCP) 获得的信息来恢复片段；在任何给定时间最多保留 2 个可恢复 LCP。当 LCP 向DIH内核块报告已完成，但节点在写入此 LCP 的最后一个全局检查点索引实际完成之前发生故障时，最新的 LCP 不可恢复。尽管应该可以使用较旧的 LCP，但假设该片段不存在 LCP，这会减慢重启过程。现在在这种情况下，使用较旧的可恢复 LCP，这应该有助于减少较长的节点重启时间。（漏洞 #81894，漏洞 #23602217）

当mysqld在处理程序初始化期间等待连接到管理服务器时 NDB，不可能关闭mysqld。如果mysqld 无法建立连接，它可能会在此时卡住。这是由于实用程序和索引统计线程中的内部等待条件可能会无限期地得不到满足。此条件已增加 1 秒的最大超时，这使得这些线程更有可能在这种情况下正确终止自身。

此外，等待管理服务器连接的连接线程在刚才描述的情况下执行了 2 次睡眠，而不是预期的 1 次睡眠。（漏洞 #81585，漏洞 #23343673）

准备中止请求时创建的延迟树节点查找请求列表在DBSPJ完成时不会被清除，这可能导致延迟操作即使在DBSPJ 请求中止后也会启动。（缺陷 #81355，缺陷 #23251423）

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

实现了错误和中止处理， 以便在传入信号处理完成之前调用Dbspj::execTRANSID_AI()其方法。abort()由于此方法向 LDM 发送信号，因此这部分覆盖了后来 所需的信号内容 execTRANSID_AI()。这可能会导致中止的DBSPJ请求过早地或根本不清理它们分配的资源。（缺陷 #81353，缺陷 #23251145）

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

代码库中的几个对象构造函数和类似函数在 NDB创建新实例时并不总是执行健全性检查。这些检查现在是在这种情况下进行的。（错误#77408，错误#21286722）

malloc()未检查对 的内部调用NULL。函数调用被直接写入所取代。（错误#77375，错误#21271194）