不兼容的更改： 当数据节点仅部分连接到 API 节点时，用于下推连接的节点可能会从不同节点上的事务协调器获取其请求，而没有（尚未）连接到 API 节点本身。在这种情况下， NodeInfo请求 API 节点的对象不包含有关 API 节点软件版本的有效信息，这导致DBSPJ块在中止时（错误地）假定 API 节点使用 NDB版本 7.2.4 或更早版本，需要在查询中止期间使用向后兼容模式，该模式发送节点故障错误而不是导致中止的真正错误。

现在，每当出现这种情况时，如果软件版本尚不可用，则假定 NDBAPI 节点版本大于 7.2.4。（漏洞 #23049170）

NDB Cluster API： 删除 Ndb 对象使用了不成比例的大量 CPU。（缺陷号 22986823）

在 MySQL NDB Cluster 7.4.8 中引入并由 API 和管理节点用于管理信号的环回传输器的保留发送缓冲区计算不正确。（漏洞 #23093656，漏洞 #22016081）

参考资料：此问题是 Bug #21664515 的回归。

在节点重启期间，重新创建用于验证外键引用完整性的内部触发器并不可靠，因为可能并非所有分布式 TC 和 LDM 实例都同意所有触发器标识。为了解决这个问题，在节点重启序列中添加了一个额外的步骤，在此期间通过查询当前主节点来确定触发器标识。（缺陷号 23068914）

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

在强制关闭集群中的 2 个数据节点之一之后 NoOfReplicas=2，由于仲裁失败，另一个数据节点也关闭了。（漏洞 #23006431）

ClusterMgr是 NDB API 和ndb_mgmd进程 的内部组件，TransporterFacade它们是传输器注册表的包装器的一部分，并与数据节点共享。该组件负责许多任务，包括连接设置请求；发送和监控心跳；提供节点状态信息；处理集群断开连接和重新连接；集群状态指标的转发。ClusterMgr维护活动节点的计数，该计数在收到节点已连接（reportConnected() 方法调用）的报告时递增，并在收到节点已从 断开连接（reportDisconnected()） 的报告时递减TransporterRegistry。此计数在检查范围内reportDisconnected()验证它是否大于零。

当节点连接由于发送缓冲区耗尽（以及其他潜在原因）而非常短暂并且刚刚描述的检查失败时，就会出现此处解决的问题。发生这种情况是因为，当一个节点没有完全连接时， reportDisconnected()尽管连接尚未报告给 ，但连接尝试仍然有可能触发调用 ClusterMgr；reportConnected()因此，和 的配对 reportDisconnected()不保证调用，这可能导致连接节点的计数被设置为零，即使仍然有节点实际上仍然连接，导致节点崩溃与 MySQL NDB Cluster 的调试构建，以及潜在的错误或其他不利影响与发布建立。

为了解决这个问题， ClusterMgr::reportDisconnected()现在验证一个断开连接的节点实际上已经完全完成连接，然后检查并减少连接节点的数量。（错误#21683144，错误#22016081）

参考资料：另请参阅：Bug #21664515、Bug #21651400。

为了降低节点的环回传输器因发送缓冲区耗尽而与传输器注册表断开连接的可能性 reportError()（通过修复 Bug #21651400 实现），现在保留了一部分发送缓冲区供此传输器使用。（错误#21664515，错误#22016081）

参考资料：另请参阅：Bug #21651400、Bug #21683144。

环回传输器类似于 TCP 传输器，但节点使用它向自身发送信号作为许多内部操作的一部分。与 TCP 传输器一样，它可能会因某些情况（包括发送缓冲区耗尽）而断开连接，但这可能会导致阻塞， TransporterFacade从而导致ndb_mgmd或 API 节点进程中出现多个问题。为防止这种情况，环回传输器断开连接的节点现在只需关闭，而不是让节点进程挂起。（漏洞 #21651400，漏洞 #22016081）

参考资料：另请参阅：Bug #21683144、Bug #21664515。