10bet网址
MySQL NDB集群7.4版本说明
下载这些版本说明
PDF (Ltr)- 0.9 mb
PDF (A4)- 0.9 mb


MySQL NDB集群7.4版本说明/ MySQL NDB集群7.4.5 (5.6.23- db-7.4.5)(2015-03-20,通用可用性)

MySQL NDB集群7.4.5 (5.6.23-ndb-7.4.5)(2015-03-20,通用可用性)

MySQL NDB Cluster 7.4.5是MySQL NDB Cluster 7.4的一个新版本,基于MySQL Server 5.6,包含了该版本7.4的功能NDB存储引擎,以及修复在以前的NDB集群版本中最近发现的错误。

获取MySQL NDB Cluster 7.4。MySQL NDB Cluster 7.4的源代码和二进制文件可以从10bet博彩公司

有关MySQL NDB Cluster 7.4中所做更改的概述,请参阅NDB集群7.4有什么新内容

该版本还包含了之前NDB集群版本中所做的所有bug修复和更改,以及从MySQL 5.6到MySQL 5.6.23主线中添加的所有bug修复和特性更改MySQL 5.6.23(2015-02-02,通用可用性)).

错误修复

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

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

    参考文献:参见:Bug #19858151, Bug #20128256, Bug #20135976。

  • NDB集群api:扫描操作(无论是单表扫描还是推入连接使用的查询扫描)将结果集存储在缓冲区中。在开始扫描操作之前,计算并预分配该缓冲区的最大大小。这个缓冲区可能会消耗大量的内存;在某些情况下,我们观察到在使用2个单线程(ndbd)数据节点。这种内存消耗随着额外片段的增加而线性增加。

    下面列出了导致这个问题的一些根本原因:

    • 结果行被解压缩到满NdbRecord格式,然后将它们存储到缓冲区中。如果只选择表的一些列,而不是所有列,则缓冲区包含空白空间(实际上是浪费了)。

    • 由于正在解压缩缓冲区格式,VARCHAR而且VARBINARY列总是必须按照为这些列定义的最大大小分配。

    • 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)

  • 如果在初始节点重新启动期间发生节点故障,然后启动另一个节点,则受影响节点的重新启动可能与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 ID的比较是可能的LCP_COMPLETE_REP带有内部值的信号SYSFILE - > latestLCP_ID失败。(Bug #76113, Bug #20631645)

  • 在发送LCP_FRAG_ORD信号作为主控接管的一部分,有可能主控不是实时同步的完全准确,因此一些信号必须被丢弃。在此期间,管理员可以发送一个LCP_FRAG_ORD信号的lastFragmentFlag即使在本地检查点完成之后也要设置。这种增强会导致该标志持续存在,直到下一个本地检查点的启动,这也会导致这些信号被丢弃。

    这种变化影响ndbd只有;没有发生所描述的问题ndbmtd.(Bug #75964, Bug #20567730)

  • 在读取和复制传输器短信号数据时,可以将数据复制回具有重叠存储器的同一信号。(Bug #75930, Bug #20553247)

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