Documentation Home
MySQL NDB Cluster 7.6.24 (5.7.40-ndb-7.6.24) 的变化（2202-10-12，全面上市）
MySQL NDB Cluster 7.6 发行说明  /  MySQL NDB Cluster 7.6.10（5.7.26-ndb-7.6.10）的变化（2019-04-26，正式发布）

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

MySQL NDB Cluster 7.6.10 是 NDB 7.6 的新版本，它基于 MySQL Server 5.7，包括 NDB存储引擎 7.6 版中的功能，并修复了之前 NDB Cluster 版本中最近发现的错误。

获取 NDB Cluster 7.6。  NDB Cluster 7.6 源代码和二进制文件可以从 https://mysql.net.cn/downloads/cluster/获得。

有关 NDB Cluster 7.6 中所做更改的概述，请参阅 NDB Cluster 7.6 中的新增功能。

此版本还合并了以前 NDB Cluster 版本中所做的所有错误修复和更改，以及通过 MySQL 5.7.26 在主线 MySQL 5.7 中添加的所有错误修复和功能更改（请参阅MySQL 5.7.26 中的更改（2019-04- 25，一般可用性））。

修正错误

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

  • 运行 NDB 7.6 及更高版本的 API 和数据节点无法使用早期版本系列中的现有解析配置，因为在为更高版本的新配置参数定义值方面过于严格，这限制了可能的升级路径。现在 NDB 7.6 及更高版本对于在它们所服务的配置中明确指定所有新参数的要求不那么严格，并且在这种情况下使用硬编码默认值。（缺陷号 28993400）

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

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

    笔记

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

    （缺陷号 28893633）

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

  • 在 LCP 状态为 IDLE 时执行来自主机的 LCP_COMPLETE_REP 信号会导致断言。（漏洞#28871889）

  • 在ndb_mgm客户端中 发出STOP命令导致 最近添加到集群的ndbmtd进程在关闭期间在第 4 阶段挂起。（漏洞#28772867）

  • 在某些情况下，一个（有时是多个）数据节点在运行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。

  • 当全局模式锁生效时，MAX_EXECUTION_TIME优化器提示和系统变量 都不会max_execution_time 被用于 DDL 语句或针对INFORMATION_SCHEMA表的查询。NDB（漏洞 #27538139）

  • 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