重要变化： 用于确保正常节点故障处理机制有时间处理可存活集群故障的最大故障时间计算（在全局检查点看门狗机制开始由于 GCP 延迟而杀死节点之前）过于保守，并且忽略了考虑在集群无法继续生存之前，最多可以发生number_of_data_nodes/ NoOfReplicas现在，NoOfReplicas在执行此计算时会正确考虑 的值。

此修复添加了 TimeBetweenGlobalCheckpointsTimeout 数据节点配置参数，使用户可以设置全局检查点之间的最小超时。此超时以前在内部固定为 120000 毫秒，现在是此参数的默认值。（漏洞 #20069617，漏洞 #20069624）

参考资料：另请参阅：Bug #19858151、Bug #20128256、Bug #20135976。

NDB Cluster APIs： 当从集群连接启动事务时， Table模式 Index对象可能会传递给此事务以供使用。如果这些模式对象是从不同的连接（Ndb_cluster_connection 对象）获取的，则可以通过删除或断开所属连接随时删除它们。这可能会留下与无效模式对象的连接，这会导致 NDB API 应用程序在取消引用这些对象时失败。

NdbTransaction::setSchemaObjectOwnerChecks() 为避免此问题，如果您的应用程序使用多个连接，您现在可以使用此版本中添加 的方法设置检查以检测在将模式对象传递给事务时连接之间的模式对象共享 。启用此检查后，将从连接中获取具有相同名称的模式对象，并将其与传递给事务的模式对象进行比较。匹配失败会导致应用程序失败并出现错误。（漏洞 #19785977）

NDB Cluster API：在 MySQL NDB Cluster 7.2.11 中，hashmap 桶的默认数量（DefaultHashMapSizeAPI 节点配置参数）从 240 增加到 3480，大大增加了内部 DictHashMapInfo::HashMap类型的大小。此类型在某些 getTable()调用中分配在堆栈上，这可能会导致 NDB API 用户出现堆栈溢出问题。

为了避免这个问题，hashmap 现在是从堆中动态分配的。（漏洞 #19306793）

NDB Cluster APIs： 扫描操作，无论是单表扫描还是推送连接使用的查询扫描，都会将结果集存储在缓冲区中。这个缓冲区的最大大小是在扫描操作开始之前计算和预分配的。该缓冲区可能会消耗大量内存；在某些情况下，我们在使用 2 个单线程 ( ndbd ) 数据节点执行 100 次并行扫描的测试中观察到 2 GB 的缓冲区占用空间。这种内存消耗被发现与额外的碎片成线性比例关系。

已发现导致此问题的许多根本原因（此处列出）：

这些问题在 NDB 7.2 和更高版本的 MySQL NDB Cluster 版本系列中变得更加明显。这是因为缓冲区大小按比例缩放BatchSize，并且从 MySQL NDB Cluster 7.2.1 开始，此参数的默认值增加了四倍（从 64 到 256）。

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

作为此修复的一部分，还进行了重构以将缓冲（打包）的处理与未缓冲的结果集的处理分开，并删除自 NDB 7.0 或更早版本以来未使用的代码。通过删除一些未使用或冗余的成员变量，NdbRecord类声明也得到了清理。（错误#73781、错误#75599、错误#19631350、错误#20408733）

测试过程中发现注册为仲裁者的节点在仲裁过程中断开或失败时会出现问题。

在这种情况下，请求仲裁的节点永远不会收到注册仲裁员的肯定确认；该节点也缺乏稳定的成员，无法启动新仲裁员的选择。

现在在这种情况下，当仲裁者失败或在仲裁过程中失去联系时，请求节点立即失败而不是等待超时。（缺陷号 20538179）

在某些平台上错误地报告了Ndb_last_commit_epoch_server 和 状态变量 的值 。Ndb_last_commit_epoch_session为更正此问题，这些值现在在内部存储为 long long，而不是 long。（缺陷号 20372169）

当数据节点发生故障或正在重新启动时，同一节点组中的其余节点会向订阅者重新发送它们确定故障节点尚未发送的任何数据。通常，当一个数据节点（实际上是 SUMA内核块）发送了属于它负责的一个时期的所有数据时，它会向 SUB_GCP_COMPLETE_REP所有订阅者发送一个信号和一个计数，每个订阅者都以一个 SUB_GCP_COMPLETE_ACK. 什么时候 SUMA从所有订阅者收到此确认后，它会将此报告给同一节点组中的其他节点，以便他们知道在后续节点发生故障的情况下无需重新发送此数据。如果一个节点在所有订阅者发送此确认之前但在同一节点组中的所有其他节点从故障节点接收到它之前发生故障，则某些时期的数据可能会发送（并报告为完整）两次，这可能会导致计划外关闭。

此问题的修复增加了 SUB_GCP_COMPLETE_ACK标识符列表报告的计数，接收器可以使用该列表来跟踪哪些桶已完成，并忽略为已完成的桶报告的任何重复项。（漏洞#17579998）

在执行重启时，有时可能会找到一个日志结束标记，该标记已被先前的重启写入，并且应该已失效。现在，在搜索要使之失效的最后一页时，使用与搜索要读取的日志的最后一页时相同的搜索算法。（错误#76207，错误#20665205）

读取和复制传输器短信号数据时，有可能将数据复制回具有重叠内存的同一信号。（错误#75930，错误#20553247）

当提早提交批量删除操作以避免额外的往返，同时还返回受影响的行数，但因超时错误而失败时，SQL 节点不执行事务是否处于已提交状态的验证。（错误#74494，错误#20092754）

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

ALTER TABLE包含针对表的注释和分区选项 的 语句NDB导致执行该语句的 SQL 节点失败。（错误#74022，错误#19667566）