重要的变化:用于确保正常节点故障处理机制有时间处理可生存的集群故障(在全局检查点看门狗机制由于GCP延迟开始杀死节点之前)的最大故障时间计算过于保守,忽略了最多可以有
number_of_data_nodes
/NoOfReplicas
集群无法继续生存之前的节点故障。现在的价值NoOfReplicas
在执行此计算时适当地加以考虑。此修复程序添加
TimeBetweenGlobalCheckpointsTimeout
数据节点配置参数,该参数使全局检查点之间的最小超时时间可由用户设置。这个超时以前在内部固定为120000毫秒,这是该参数现在的默认值。(Bug #20069617, Bug #20069624)参考文献:参见:Bug #19858151, Bug #20128256, Bug #20135976。
NDB集群接口:当事务从集群连接启动时,
表格
而且指数
Schema对象可以传递给这个事务使用。如果从不同的连接获取了这些模式对象(Ndb_cluster_connection
对象),可以通过删除或断开所属连接在任何位置删除它们。这可能会使连接保留无效的模式对象,从而导致NDB API应用程序在解引用这些对象时失败。方法可避免此问题,如果应用程序使用多个连接,那么现在可以设置一个检查,以便在向事务传递模式对象时检测连接之间的模式对象共享
NdbTransaction: setSchemaObjectOwnerChecks ()
方法中添加的。当启用此检查时,将从连接获取具有相同名称的模式对象,并将其与传递给事务的模式对象进行比较。匹配失败将导致应用程序失败并出现错误。(错误# 19785977)NDB集群接口:默认hashmap桶数量的增加(
DefaultHashMapSize
API节点配置参数)从240到3480在MySQL NDB集群7.2.11增加了内部的大小DictHashMapInfo: HashMap
类型。该类型在某些类型的堆栈上分配可以获得的()
调用,这可能导致NDB API用户的堆栈溢出问题。为了避免这个问题,现在从堆动态分配哈希映射。(错误# 19306793)
NDB集群接口:扫描操作(无论是单表扫描还是推入连接使用的查询扫描)将结果集存储在缓冲区中。在开始扫描操作之前,计算并预分配该缓冲区的最大大小。这个缓冲区可能会消耗大量的内存;在某些情况下,我们观察到在使用2个单线程(ndbd)数据节点。这种内存消耗随着额外片段的增加而线性增加。
下面列出了导致这个问题的一些根本原因:
结果行被解压缩到满
NdbRecord
格式,然后将它们存储到缓冲区中。如果只选择表的一些列,而不是所有列,则缓冲区包含空白空间(实际上是浪费了)。BatchByteSize
而且MaxScanBatchSize
在计算最大缓冲区大小时,没有将值作为限制因素考虑在内。
这些问题在NDB 7.2和后来的MySQL NDB集群发行系列中变得更加明显。这是由于缓冲区大小按比例缩放的事实
BatchSize
从MySQL NDB Cluster 7.2.1开始,该参数的默认值增加了四倍(从64增加到256)。此修正导致结果行使用打包格式而不是解打包格式进行缓冲;缓冲的扫描结果行现在不会被解包,直到它成为当前行。此外,
BatchByteSize
而且MaxScanBatchSize
在计算所需的缓冲区大小时,现在用作限制因素。同样作为修复的一部分,重构已经完成,将缓冲(打包)的处理与未缓冲的结果集的处理分开,并删除自NDB 7.0或更早版本以来未使用的代码。的
NdbRecord
通过删除一些未使用或冗余的成员变量,类声明也得到了清理。(Bug #73781, Bug #75599, Bug #19631350, Bug #20408733)在测试过程中发现,当注册为仲裁员的节点在仲裁过程中断开连接或失败时,可能会出现问题。
在这种情况下,请求仲裁的节点永远无法从注册仲裁员那里收到肯定的确认;该节点还缺乏稳定的成员集,无法启动新仲裁者的选择。
现在,在这种情况下,当仲裁人在仲裁期间失败或失去联系时,请求节点立即失败,而不是等待超时。(错误# 20538179)
的值
Ndb_last_commit_epoch_server
而且Ndb_last_commit_epoch_session
某些平台的状态变量报告错误。为了纠正这个问题,这些值现在在内部存储为很久很久
,而不是长
.(错误# 20372169)当一个数据节点发生故障或正在重新启动时,同一节点组中的其他节点将向订阅者重新发送它们认为故障节点尚未发送的任何数据。通常,当数据节点(实际上是
SUMA
内核块)发送所有属于它负责的epoch的数据时,它发送一个SUB_GCP_COMPLETE_REP
向所有订阅者发送信号,其中每个订阅者都响应一个SUB_GCP_COMPLETE_ACK
.当SUMA
从所有订阅者处接收此确认,它将此消息报告给同一节点组中的其他节点,以便它们知道在后续节点故障时不需要重新发送此数据。如果一个节点在所有订阅者发送此确认之前失败,但在同一节点组中的所有其他节点从失败节点接收到此确认之前失败,则可能两次发送(并报告为完成)某些时期的数据,这可能导致计划外的关闭。对该问题的修复增加了报告的计数
SUB_GCP_COMPLETE_ACK
一个标识符列表,接收端可以使用它来跟踪哪些桶已经完成,并忽略已经完成的桶的任何重复报告。(错误# 17579998)在执行重新启动时,有时可能会发现由上一次重新启动写入的日志结束标记,该标记应该已经失效。现在,在搜索要使最后一页失效时,使用与搜索要读取的日志的最后一页时相同的搜索算法。(Bug #76207, Bug #20665205)
在读取和复制传输器短信号数据时,可以将数据复制回具有重叠存储器的同一信号。(Bug #75930, Bug #20553247)
当批量删除操作提前提交以避免额外的往返,同时也返回受影响的行数,但失败并出现超时错误时,SQL节点没有执行任何验证事务是否处于committed状态的操作。(Bug #74494, Bug #20092754)
参考文献:参见Bug #19873609。
一个
ALTER TABLE
控件上包含注释和分区选项的NDB
表导致执行它的SQL节点失败。(Bug #74022, Bug #19667566)