Documentation Home
MySQL NDB Cluster 7.4 发行说明  / 发布系列变更日志:MySQL NDB Cluster 7.4  /  MySQL NDB Cluster 7.3.7 (5.6.21-ndb-7.3.7) 的变化(2014-10-17,全面上市)

MySQL NDB Cluster 7.3.7 (5.6.21-ndb-7.3.7) 的变化(2014-10-17,全面上市)

添加或更改的功能

  • 在将新数据节点添加到具有许多 API 节点的 MySQL NDB Cluster 的配置文件中之后,但在启动任何数据节点进程之前,API 节点每秒 尝试多次连接到这些 丢失的数据节点,从而增加了额外的负载在管理节点和网络上。为了减少以这种方式造成的不必要的流量,现在可以控制 API 节点在尝试连接到未能响应的数据节点之间等待的时间量;这是在两个新的 API 节点配置参数 StartConnectBackoffMaxTime 和 中实现的ConnectBackoffMaxTime

    应用这些参数时,不考虑节点连接尝试期间经过的时间,这两个参数均以毫秒为单位,分辨率约为 100 毫秒。只要 API 节点未如前所述连接到任何数据节点, StartConnectBackoffMaxTime就会应用参数值;否则,ConnectBackoffMaxTime被使用。

    在具有许多未启动数据节点的 MySQL NDB Cluster 中,可以提高这些参数的值以规避对尚未开始在集群中运行的数据节点的连接尝试,以及对管理节点的适度高流量。

    有关这些参数的行为的更多信息,请参阅 在 NDB Cluster 中定义 SQL 和其他 API 节点。(漏洞 #17257842)

  • 添加了 ndb_restore--exclude-missing-tables的 选项。启用后,该选项会导致备份中存在但目标数据库中不存在的表被忽略。(错误#57566,错误#11764704)

修正错误

  • NDB Cluster API: 错误 #16723708 的修复阻止了 ndb_logevent_get_next() 函数将日志事件 ndb_mgm_event_category转换为 enum类型,但此更改干扰了现有应用程序,因此现在恢复了函数的原始行为。此版本中添加了一个展示更正行为的新 MGM API 函数 ndb_logevent_get_next2(),以取代还原的函数,用于不需要向后兼容性的应用程序。除此以外,新功能在所有其他方面与其前身相同。(漏洞 #18354165)

    参考资料:恢复补丁:Bug #16723708。

  • NDB Cluster API: 当操作导致错误时, NDB API 会在调用后扫描泄漏 Ndb_cluster_connection对象 nextResult()此泄漏会锁定 DBTC内核块中的相应连接对象,直到连接关闭。(错误#17730825,错误#20170731)

  • 当组装形式为节点n状态不正确状态的错误消息时: node_state,当传输器连接失败时写入,在许多实例中使用节点状态代替节点 ID,这导致节点的这种类型的错误状态报告不正确。(缺陷 #19559313,缺陷 #73801)

  • 在某些情况下,传输器接收缓冲区在被另一个线程读取时被一个线程重置。当一个线程接收数据和另一个线程启动传输器断开连接(断开连接清除此缓冲区)之间发生竞争条件时,就会发生这种情况。现在已实施并发逻辑以防止发生这种竞争。(缺陷 #19552283,缺陷 #73790)

  • 在某些情况下,数据节点的故障可能会导致一组 API 节点也因发送 CLOSE_COMREQ有时未完全初始化的信号而失败。(漏洞 #19513967)

  • NDB如果其中一个内部 方法 出现严重故障,sendSignal*()在进程崩溃之前,将打印一份更详细的错误报告,这已经为 实施 sendSignal(),但更专业的sendSignalNoRelease()方法中缺少。在某些情况下,正确报告此类崩溃有助于识别配置硬件问题。(漏洞 #19414511)

    参考资料:另请参阅:错误 #19390895。

  • 当有超过大约 17 K 的数据对象时, ndb_restore无法恢复集群的元数据。(漏洞 #19202654)

  • 解决先前处理多节点故障的问题需要确定故障节点正在运行的 TC 实例的数量,然后接管它们。确定此数量的机制有时会提供无效结果,导致故障节点中的 TC 实例数量被设置为过高的值。这反过来又导致了冗余的接管尝试,这浪费了时间并对其他节点故障和全局检查点的处理产生了负面影响。(漏洞 #19193927)

    参考资料:此问题是 Bug #18069334 的回归。

  • 在删除同一元组之前立即执行读取的并行事务可能会导致NDB 内核崩溃。ThreadConfig 当使用配置参数指定单独的 TC 线程时,更有可能发生这种情况 。(漏洞 #19031389)

  • 在某些情况下, ndb_restore未正确处理 不同 TEXT类型( 、 、 和 中的任何一种 TINYTEXTTEXT之间 MEDIUMTEXT的 属性提升。此外,值现在根据 mysqld设置的限制被截断(例如, 从另一种类型转换为的值被截断为 256 字节)。对于使用多字节字符集的列,值将被截断到最后一个格式正确的字符的末尾。 LONGTEXTTEXTTINYTEXT

    此外,由于此修复, TEXT现在不允许转换为使用与原始字符集不同的字符集的任何大小的列。(漏洞 #18875137)

  • 为了协助解决引发许多看门狗警告的诊断问题,现在可以DUMP 2610ndb_mgm客户端中使用激活(或停用)杀手看门狗。设置后,这将关闭下一个看门狗警告发生的数据节点,并提供跟踪日志。(漏洞 #18703922)

  • 优化的NDB节点恢复机制尝试仅将相关页面更改传输到起始节点,以加快恢复过程;这是通过让起始节点指示其参与的最后一个全局检查点 (GCI) 的索引来完成的,以便已经运行的节点仅复制自该 GCI 以来已更改的行的数据。每行都有一个 GCI 元列,这有助于实现这一点;对于已删除的行,以前存储该行数据的槽包含 GCI 值,对于已删除的页面,丢失页面上的每一行都被认为已更改,因此需要发送。

    当起始节点接收到这些更改时,该节点将查找页面和索引以确定它们包含的内容。此查找可能导致将真实的底层页面映射到逻辑页面 ID,即使该页面不包含任何数据也是如此。

    在集群使用率接近最大值后,出现此问题的一种方式是DataMemory删除许多行,然后滚动重启数据节点,期望这会释放内存,但实际上在这种情况下是可能的为了不释放内存,在某些情况下,内存使用实际上增加到最大值。

    此修复通过确保仅当此页面包含需要存储的实际数据时在节点恢复期间将真实物理页面映射到逻辑 ID 来解决这些问题。(错误#18683398,错误#18731008)

  • 当数据节点MISSING_DATA由于缓冲区溢出而发送信号并且当前 epoch 还没有发送事件数据时,为处理这种不一致而创建的虚拟事件列表在将虚拟事件列表中的信息传输到完成后不会被删除列表。(漏洞 #18410939)

  • 在缓存范围末尾手动插入后,下一个自动增量值的计算不正确可能会导致有时使用重复值。auto_increment_increment当使用、 auto_increment_offset和 的某些值组合时,此问题可能会自行显现ndb_autoincrement_prefetch_sz

    此问题已通过修改计算得到修复,以确保缓存中计算出的下一个值 NDB的格式为 。这避免了 MySQL 服务器对返回值进行任何四舍五入,当四舍五入的值超出缓存值的范围时,这可能会导致重复条目。(漏洞#17893872)auto_increment_offset + (N * auto_increment_incrementNDB

  • ndb_show_tables --help输出包含关于 --database (-d) 选项的误导性信息。此外,选项 (--database) 的长格式无法正常工作。(漏洞 #17703874)

  • --help选项与 ndb_print_file一起使用会导致程序出现段错误。(漏洞 #17069285)

  • 对于多线程数据节点,一些线程确实经常通信,结果是非常旧的信号可以保留在信号缓冲区的顶部。在执行线程跟踪时,信号转储程序根据它在信号缓冲区中找到的内容计算出最新的信号 ID,这意味着这些旧信号可能会被错误地计为最新信号。现在,信号 ID 计数器保留为线程状态的一部分,在为跟踪文件转储信号时使用的正是这个值。(错误#73842,错误#19582807)