重要的变化:用于确保正常节点故障处理机制有时间来处理可存活的集群故障(在全局检查点看门狗机制由于GCP延迟开始杀死节点之前)的最大故障时间计算过于保守，忽略了可能存在最多的故障时间number_of_data_nodes/NoOfReplicas节点故障在群集之前不再存活。现在的价值NoOfReplicas在执行此计算时应适当考虑。

此修复程序添加了TimeBetweenGlobalCheckpointsTimeout数据节点配置参数，它使用户可以设置全局检查点之间的最小超时。这个超时以前在内部固定为120000毫秒，这现在是这个参数的默认值。(Bug #20069617, Bug #20069624)

参考文献：另见：bug＃19858151，bug＃20128256，bug＃20135976。

NDB集群api:扫描操作，无论是单表扫描还是push连接使用的查询扫描，都将结果集存储在缓冲区中。在开始扫描操作之前，计算并预分配该缓冲区的最大大小。这个缓冲区可能会消耗大量的内存;在某些情况下，我们在使用2个单线程执行100个并行扫描(ndbd）数据节点。发现此内存消耗与其他碎片线性缩放。

这里列出了许多根本原因，被发现导致这个问题：

在NDB 7.2和更高版本的MySQL NDB集群释放系列中，这些问题变得更加明显。这是由于缓冲区大小缩放BatchSize，并且使用MySQL NDB群集7.2.1开头，此参数的默认值增加了四倍（从64到256）。

此修复导致结果行使用已打包格式而不是未打包格式进行缓冲;缓冲扫描结果行现在不会被解包，直到它成为当前行。此外,BatchByteSize和MaxScanBatchSize现在在计算所需的缓冲区大小时用作限制因素。

此外，作为此修复的一部分，已经完成了重构以将缓冲（包装）的处理分开处理未缓冲的结果集，并删除自NDB 7.0或更早版本以来未使用的代码。这NdbRecord除了删除多个未使用或冗余成员变量，还清理了类声明。（bug＃73781，bug＃75599，bug＃19631350，bug＃20408733）

如果在初始节点重新启动期间的节点发生故障，后跟另一个节点开始，则受影响的节点的重新启动可以挂起START_INFOREQ发生在本地检查点的无效仍然正在进行中。（bug＃20546157，bug＃75916）

参考:参见Bug #34702。

在测试期间发现，当在仲裁过程中注册为仲裁器的节点时，可能会出现问题。

在这种情况下，请求仲裁的节点永远无法从注册的仲裁员接收积极确认;此节点还缺少一组稳定的成员，无法启动新仲裁员的选择。

现在，在这种情况下，当仲裁程序失败或仲裁过程中失去联系时，请求节点将立即失败，而不是等待超时。(错误# 20538179)

删除数据库当数据库目录包含一个时无法删除数据库.ndb中没有对应表的文件NDB。现在，执行时删除数据库，NDB特别对剩余部分进行检查.ndb文件，并删除它找到的任何内容。(错误# 20480035)

参考:参见Bug #44529。

在执行重新启动时，有时可能会找到一个日志结束标记，它是由以前的重新启动编写的，应该是无效的。现在，当搜索要使其失效的最后一页时，将使用与搜索要读取的日志的最后一页时相同的搜索算法。(Bug #76207, Bug #20665205)

在节点重启期间，如果没有完成全局检查点START_LCP_REQ对于本地检查站及其LCP_COMPLETE_REP可以比较发送的LCP IDLCP_COMPLETE_REP信号具有内部值sysfile-> lo nallcp_id.失败。（bug＃76113，bug＃20631645）

在发送lcp_frag_ord.信号作为主收购的一部分，母部可能无法实时与完全精度同步，从而必须丢弃一些信号。在此期间，主人可以发送一个lcp_frag_ord.信号的LastfragmentFlag.即使在本地检查站完成后，也会设置。此增强功能导致此标志持续到直到下一个本地检查点的STATRT，这也导致这些信号丢弃。

这种变化影响ndbd只有;描述的问题没有发生在ndbmtd.。（bug＃75964，bug＃20567730）

当读取和复制运输机短信号数据时，可以将数据复制回与重叠存储器的相同信号。（bug＃75930，bug＃20553247）

NDB节点接管代码假设在启动接管时只有一条接管记录，进一步假设主节点永远不会执行片段复制。但是，在系统重新启动时就不是这样了，在系统重新启动时，主节点可能有过时的数据，因此需要执行这样的复制来更新自己。(Bug #75919, Bug #20546899)