-
重要变化: 用于确保正常节点故障处理机制有时间处理可存活集群故障的最大故障时间计算(在全局检查点看门狗机制开始由于 GCP 延迟而杀死节点之前)过于保守,并且忽略了考虑在集群无法继续生存之前,最多可以发生
number_of_data_nodes
/NoOfReplicas
现在,NoOfReplicas
在执行此计算时会正确考虑 的值。此修复添加了
TimeBetweenGlobalCheckpointsTimeout
数据节点配置参数,使用户可以设置全局检查点之间的最小超时。此超时以前在内部固定为 120000 毫秒,现在是此参数的默认值。(漏洞 #20069617,漏洞 #20069624)参考资料:另请参阅:Bug #19858151、Bug #20128256、Bug #20135976。
-
NDB Cluster APIs: 扫描操作,无论是单表扫描还是推送连接使用的查询扫描,都会将结果集存储在缓冲区中。这个缓冲区的最大大小是在扫描操作开始之前计算和预分配的。该缓冲区可能会消耗大量内存;在某些情况下,我们在使用 2 个单线程 ( ndbd ) 数据节点执行 100 次并行扫描的测试中观察到 2 GB 的缓冲区占用空间。这种内存消耗被发现与额外的碎片成线性比例关系。
已发现导致此问题的许多根本原因(此处列出):
结果行在
NdbRecord
存储到缓冲区之前被解压缩为完整格式。如果只选择了表的一些列而不是所有列,则缓冲区包含空白空间(基本上是浪费的)。BatchByteSize
在计算最大缓冲区大小时,MaxScanBatchSize
值未被视为限制因素。
这些问题在 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) -
如果在初始节点重启和另一个节点启动期间发生节点故障,受影响节点的重启可能会挂起,
START_INFOREQ
而本地检查点的失效仍在进行中。(缺陷 #20546157,缺陷 #75916)参考资料:另请参阅:错误 #34702。
-
测试过程中发现注册为仲裁者的节点在仲裁过程中断开或失败时会出现问题。
在这种情况下,请求仲裁的节点永远不会收到注册仲裁员的肯定确认;该节点也缺乏稳定的成员,无法启动新仲裁员的选择。
现在在这种情况下,当仲裁者失败或在仲裁过程中失去联系时,请求节点立即失败而不是等待超时。(缺陷号 20538179)
-
DROP DATABASE
当数据库目录包含一个.ndb
在NDB
. 现在,在执行时DROP DATABASE
,NDB
专门针对剩余.ndb
文件执行检查,并删除它找到的任何文件。(缺陷号 20480035)参考资料:另请参阅:Bug #44529。
在执行重启时,有时可能会找到一个日志结束标记,该标记已被先前的重启写入,并且应该已失效。现在,在搜索要使之失效的最后一页时,使用与搜索要读取的日志的最后一页时相同的搜索算法。(错误#76207,错误#20665205)
START_LCP_REQ
在节点重启期间,如果在本地检查点和它 之间没有完成全局检查点LCP_COMPLETE_REP
,则信号中发送的 LCP IDLCP_COMPLETE_REP
与内部值的比较可能SYSFILE->latestLCP_ID
会失败。(错误#76113,错误#20631645)-
当发送
LCP_FRAG_ORD
信号作为主机接管的一部分时,主机可能没有实时完全准确地同步,因此必须丢弃一些信号。在此期间,即使在本地检查点完成后,master 也可以发送LCP_FRAG_ORD
带有其设置的信号 。lastFragmentFlag
此增强功能导致此标志一直持续到下一个本地检查点的 statrt,这也会导致这些信号被丢弃。此更改仅影响ndbd;ndbmtd没有出现所描述的问题。(错误#75964,错误#20567730)
读取和复制传输器短信号数据时,有可能将数据复制回具有重叠内存的同一信号。(错误#75930,错误#20553247)
NDB 节点接管代码假设在开始接管时只有一个接管记录,这是基于主节点永远不会执行分片复制的进一步假设。然而,在系统重启时情况并非如此,主节点可能拥有陈旧数据,因此需要执行此类复制以使其自身保持最新状态。(错误#75919,错误#20546899)