Documentation Home
MySQL NDB Cluster 7.5 发行说明
MySQL NDB Cluster 7.5 发行说明  / 发布系列变更日志：MySQL NDB Cluster 7.5  /  MySQL NDB Cluster 7.5.14（5.7.26-ndb-7.5.14）的变化（2019-04-26，正式发布）

MySQL NDB Cluster 7.5.14（5.7.26-ndb-7.5.14）的变化（2019-04-26，正式发布）

修正错误

  • NDB 磁盘数据： NDB没有正确验证 MaxNoOfOpenFiles， InitialNoOfOpenFiles 导致数据节点失败，并显示错误消息，用户没有清楚地了解问题的性质。（漏洞#28943749）

  • NDB Disk Data：针对同一个表空间 重复执行 ALTER TABLESPACE ... ADD DATAFILE导致数据节点挂起并离开，手动杀死后无法重启。（漏洞 #22605467）

  • NDB Cluster API： NDB现在识别不需要减少锁争用的短期事务，并且 NdbBlob::close()在解锁仅导致额外工作和往返之前执行的情况下（例如启用自动提交时）不再调用此方法提交或中止事务。（漏洞 #29305592）

    参考资料：另请参阅：Bug #49190、Bug #11757181。

  • NDB Cluster APIs： 当最近失败的操作被释放时，指向它的指针 NdbTransaction变得无效，并且在访问时导致 NDB API 应用程序失败。（漏洞#29275244）

  • 当在DBSPJ 块中执行的推送连接必须在查询执行期间存储相关 ID 时，会在整个查询执行的生命周期内为这些分配内存，即使仅在生成结果集中的最新批次时才需要这些特定的相关 ID . 后续批次需要存储和分配额外的相关 ID；因此，如果查询花费了足够长的时间才能完成，则会导致查询内存耗尽（错误 20008）。现在在这种情况下，内存仅在当前结果批次的生命周期内分配，并在批次完成后释放并可供重新使用。（缺陷号 29336777）

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

  • 添加DUMP 406 ( NdbfsDumpRequests) 以向 NDB节点日志中的全局检查点和本地检查点停止报告提供文件系统信息。（漏洞 #28922609）

  • 当同一行的事务中的不同操作同时准备和中止时，内核块DBACC和 内核块 之间会出现竞争条件。DBLQH这可能导致在 DBTUP先前的操作已中止时尝试准备操作，这是意外的，因此可能导致未定义的行为，包括潜在的数据节点故障。为了解决这个问题，DBACC现在 DBLQH在尝试准备操作之前检查所有依赖项是否仍然有效。

    笔记

    此修复程序还取代了之前针对相关问题所做的修复程序，该问题最初报告为 Bug #28500861。

    （缺陷号 28893633）

  • 该ndbinfo.cpustat表报告了有关发送线程的不准确信息。（漏洞#28884157）

  • 在某些情况下，一个（有时是多个）数据节点在运行ndb_restore时经历了计划外关闭。这种情况最常发生，但并不总是发生在恢复到具有与原始备份所在的集群不同数量的数据节点的集群时。

    此问题的根本原因是 SafeCounter对象 池耗尽，DBDICT内核块将其用作执行模式事务的一部分，并取自与用于NDB事件设置和订阅处理的协议共享的每个块实例池。事件设置和订阅处理的并发使得 SafeCounter池可以被耗尽；事件和订阅处理可以处理池耗尽，但模式事务处理不能，这可能导致节点在恢复期间关闭。

    DBDICT 通过为模式事务提供一个隔离的保留池 来解决此问题，该池SafeCounters不会被并发NDB事件活动耗尽。（漏洞 #28595915）

  • 由于错误导致提交失败后，mysqld 在尝试获取所涉及的表的名称时意外关闭。这是由于内部功能的问题 ndbcluster_print_error()。（漏洞 #28435082）

  • 当使用一个或多个登台表时， ndb_restore未正确恢复自动增量值。作为此修复的一部分，我们还在这种情况下阻止应用 SYSTAB_0备份日志，其内容继续直接根据表 ID 应用，这可能会覆盖存储在 SYSTAB_0不相关表中的自动增量值。（错误#27917769，错误#27831990）

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

  • ndb_restore采用了一种恢复非原子自动增量值的机制，因此当并行使用多个ndb_restore实例时，可能会产生不正确的自动增量值。（漏洞 #27832033）

    参考资料：另请参阅：Bug #27917769、Bug #27831990。

  • DBSPJ 当为延迟操作存储相关 ID 时内核块 中的查询内存耗尽时，查询被中止，错误状态为 20000 Query aborted due to out of query memory。（漏洞#26995027）

    参考资料：另请参阅：错误 #86537。

  • MaxBufferedEpochs用于数据节点，以避免由于滞后的NDB事件 API 订阅者而对行更改进行过度缓冲；当来自一个或多个订阅者的纪元确认滞后这个纪元数时，将触发异步断开连接，从而允许数据节点释放用于订阅的缓冲区空间。由于这种断开是异步的，可能是在数据节点上完成额外的新纪元之前它还没有完成，导致新纪元无法获取 GCP 完成记录，生成如下所示的警告： 

        [ndbd] ERROR    -- c_gcp_list.seize() failed...

    ...

    [ndbd] WARNING  -- ACK wo/ gcp record...

    并导致以下警告： 

        Disconnecting node %u because it has exceeded MaxBufferedEpochs
    (100 > 100), epoch ....

    此修复程序执行以下修改：

    • 修改 GCP 完成记录池的大小，以确保始终有一些额外的空间来考虑前面描述的断开连接处理的异步性质，从而避免占用 c_gcp_list失败。

    • 修改 MaxBufferedEpochs警告的措辞以避免出现矛盾的短语“ 100 > 100 ”。

    （缺陷号 20344149）

  • 在调试模式下执行重做日志时，数据节点可能会在取消分配行时失败。（缺陷 #93273，缺陷 #28955797）

  • 一个表在另一个表NDB上同时使用外键和一个或多个 或 列泄漏内存。 NDBON DELETE CASCADETEXTBLOB

    作为此修复的一部分， 当子表包含使用任何或类型的列时，表ON DELETE CASCADE上的外键不再受支持。（漏洞 #89511，漏洞 #27484882）NDBBLOBTEXT