MySQL NDB ClusterJ:使ClusterJ更容易处理需要SessionFactory要封闭，新的公开方法就在SessionFactory接口,getConnectionPoolSessionCounts ()，已经被创建。当它为所有池连接返回0时，意味着所有会话都已关闭，此时SessionFactory可以关闭和重新打开。看到错误处理和重新连接了解更多细节。(错误# 22353594)

不兼容的更改:当数据节点只部分连接到API节点时，用于下推连接的节点可以从另一个节点上的事务协调器获得请求，而(尚未)连接到API节点本身。在这种情况下，NodeInfo对象中没有包含API节点软件版本的有效信息，导致DBSPJ块假设(不正确地)中止时假设API节点使用NDB版本7.2.4或更早的版本，要求在查询中止期间使用向后兼容模式，这将发送一个节点失败错误，而不是导致中止的真正错误。

现在，无论何时出现这种情况，都可以假设，如果NDB软件版本不存在，API节点版本大于7.2.4。(错误# 23049170)

NDB集群接口:删除Ndb对象会占用过多的CPU。(错误# 22986823)

MySQL NDB集群7.4.8中引入的、API和管理节点用于管理信号的环回传输器预留发送缓冲区计算错误。(Bug #23093656, Bug #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集群的调试版本的节点崩溃，以及潜在的错误或其他负面影响的发布版本。

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

参考文献:参见Bug #21664515, Bug #21651400。

减少节点的环回传输器与传输器注册表断开连接的可能性reportError ()由于发送缓冲区耗尽(由Bug #21651400的修复实现)，发送缓冲区的一部分现在被保留给这个传输器使用。(Bug #21664515, Bug #22016081)

参考文献:参见Bug #21651400, Bug #21683144。

环回传输器类似于TCP传输器，但节点使用环回传输器向自身发送信号，作为许多内部操作的一部分。与TCP传输器一样，它可能会由于某些条件(包括发送缓冲区耗尽)而断开连接，但这可能会导致阻塞TransporterFacade所以会在一个ndb_mgmd或API节点进程。为了防止这种情况，一个环回传输器断开连接的节点现在只需关闭，而不允许节点进程挂起。(Bug #21651400, Bug #22016081)

参考文献:参见Bug #21683144, Bug #21664515。