restart_info将表格 添加到ndbinfo信息数据库以提供与节点和系统重启相关的当前状态和时间信息。通过查询该表，可以实时观察重启进度。（漏洞 #19795152）

在将新数据节点添加到具有许多 API 节点的 MySQL NDB Cluster 的配置文件中之后，但在启动任何数据节点进程之前，API 节点每秒 尝试多次连接到这些 “丢失”的数据节点，从而增加了额外的负载在管理节点和网络上。为了减少以这种方式造成的不必要的流量，现在可以控制 API 节点在尝试连接到未能响应的数据节点之间等待的时间量；这是在两个新的 API 节点配置参数 StartConnectBackoffMaxTime 和 中实现的ConnectBackoffMaxTime。

应用这些参数时，不考虑节点连接尝试期间经过的时间，这两个参数均以毫秒为单位，分辨率约为 100 毫秒。只要 API 节点未如前所述连接到任何数据节点， StartConnectBackoffMaxTime就会应用参数值；否则，ConnectBackoffMaxTime被使用。

在具有许多未启动数据节点的 MySQL NDB Cluster 中，可以提高这些参数的值以规避对尚未开始在集群中运行的数据节点的连接尝试，以及对管理节点的适度高流量。

有关这些参数的行为的更多信息，请参阅 在 NDB Cluster 中定义 SQL 和其他 API 节点。（漏洞 #17257842）

在执行批量更新时，从批处理开始的一个或多个成功的写入操作之后是失败但未中止的写入操作（由于 AbortOption设置为AO_IgnoreError），事务协调器对这些操作的失败处理会泄漏 CommitAckMarker资源。（漏洞#19875710）

参考资料：此问题是 Bug #19451060、Bug #73339 的回归。

当 MySQL NDB Cluster 7.4 master 试图从已经运行 NDB 7.3 的数据节点请求一个包含 32 个片段的本地检查点时，在线降级到 MySQL NDB Cluster 7.3 失败，NDB 7.3 仅支持 2 个片段用于 LCP。现在在这种情况下，NDB 7.4 master 在发出请求之前确定数据节点可以处理多少片段。（漏洞 #19600834）

解决先前处理多节点故障的问题需要确定故障节点正在运行的 TC 实例的数量，然后接管它们。确定此数量的机制有时会提供无效结果，导致故障节点中的 TC 实例数量被设置为过高的值。这反过来又导致了冗余的接管尝试，这浪费了时间并对其他节点故障和全局检查点的处理产生了负面影响。（漏洞 #19193927）

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

如果服务器端的节点尚未准备好接收来自其他节点的连接，则 NDB 传输器的服务器端在握手阶段非常快速地断开传入的客户端连接。当客户端立即再次尝试连接到服务器套接字时，这会导致问题，但又会再次断开连接，如此反复，直到成功为止。由于每次客户端连接尝试都会在 中留下一个套接字TIME_WAIT，因此套接字的数量TIME_WAIT会迅速增加，进而导致传输器服务器端的节点出现问题。

对问题和代码的进一步分析表明，问题的根源在于传输连接协议的握手部分。为了避免发生前面描述的问题，服务器端的节点现在 WAIT会在节点尚未准备好接受握手时发回一条消息，而不是断开套接字。这意味着客户端不再需要为下一次重试创建新的套接字，而是可以立即开始新的握手问候消息。（漏洞 #17257842）

发送到数据节点的损坏消息有时未被发现，导致将错误信号传递到中止数据节点的块。这种故障与断开节点相结合可能反过来导致整个集群关闭。

为了防止这种情况发生，现在在解包通过 TCP 接收到的信号时会进行额外的检查，包括检查字节顺序、压缩标志（不得使用）以及接收缓冲区中下一条消息的长度（如果有的话） ).

每当两个连续的解包消息未能通过刚才描述的检查时，就假定当前消息已损坏。在这种情况下，传输器被标记为具有错误数据，并且在重新连接传输器之前不会再对消息进行解包。此外，一个条目被写入集群日志，其中包含错误以及损坏消息的十六进制转储。（错误#73843，错误#19582925）

在恢复操作期间，当从接收缓冲区读取可变长度属性而不是属性的实际长度时，使用了属性的最大长度。（错误#73312，错误#19236945）