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.7 (5.7.23-ndb-7.6.7) 的变化（2018-07-27，正式发布）

MySQL NDB Cluster 7.6.7 (5.7.23-ndb-7.6.7) 的变化（2018-07-27，正式发布）

MySQL NDB Cluster 7.6.7 是 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.23 在主线 MySQL 5.7 中添加的所有错误修复和功能更改（请参阅MySQL 5.7.23 中的更改（2018-07- 27，一般可用性））。

添加或更改的功能

  • 作为改进本地检查点处理和最大限度减少 LCP 期间与错误 410（REDO 日志过载）相关问题发生的持续工作的一部分， NDB现在实施自适应 LCP 控制，根据重做日志使用情况调节 LCP 扫描优先级和 LCP 写入。

    对 NDB配置参数进行了以下更改：

    • 默认值 RecoveryWork从 50 增加到 60（为 LCP 文件保留 60% 的存储空间）。

    • 新 参数控制为插入操作保留InsertRecoveryWork 的百分比 。RecoveryWork默认值为 40（40% of RecoveryWork）；最小值和最大值分别为 0 和 70。增加此值允许在 LCP 期间进行更多写入，同时限制 LCP 的总大小。减少InsertRecoveryWork 限制 LCP 期间使用的写入次数，但会导致使用更多空间。

    NDB实施 LCP 控制可为部署 带来多项好处 。使用默认配置的集群现在应该比以前更好地承受重负载，并且现在应该可以在可用磁盘空间大约是分配给集群的内存量的 2.1 倍的系统上可靠地运行它们（即， DataMemory） 或者更多。重要的是要记住，刚刚引用的数字并未考虑磁盘上表使用的磁盘空间。

    在对重做日志大小减小的单个数据节点进行负载测试期间，可以成功地将大量数据加载到 NDB 中，并为重做日志保留 16GB，同时在任何时候使用不超过 50% 的重做日志时间。

    有关更多信息，请参阅NDB Cluster 7.6 中的新增功能以及前面提到的参数的描述。（错误#90709、错误#27942974、错误#27942583）

    参考资料：另请参阅：Bug #27926532、Bug #27169282。

修正错误

  • ndbinfo 信息数据库： 重启后可能会使用（有时不完整的）回退数据来填充 ndbinfo.processes表，这可能导致此表中的行具有空 process_name值。此类回退数据不再用于此目的。（漏洞#27985339）

  • NDB 客户端程序：ndb_setup.py 不再使用 可执行文件host_info。此文件及其父目录 share/mcc/host_info已从 NDB Cluster 分发中删除。

    此外，与未使用 dojo.zip文件相关的安装程序代码已被删除。（错误#90743、错误#27966467、错误#27967561）

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

  • MySQL NDB ClusterJ： 无法使用 JDK 9 从源代码构建 ClusterJ。（缺陷 #27977985）

  • 还原操作在NDB以下情况下失败：

    • 一个数据节点被重启

    • 正在恢复的片段的本地检查点使用了两个.ctl文件

    • 这些.ctl文件中的第一个是正在使用的文件

    • 有问题的 LCP 由 2002 多个零件组成

    发生这种情况是因为用于解压文件的数组 .ctl仅包含 2002 个元素，导致内存被覆盖，因为该数据最多可包含 2048 个部分。此问题已通过增加数组大小以容纳 2048 个元素来解决。（漏洞 #28303209）

  • 本地检查点并不总是 DROP TABLE正确处理操作。（漏洞 #27926532）

    参考资料：此问题是 Bug #26908347、Bug #26968613 的回归。

  • 在 的执行过程中 ，只要发现请求的表已经存在CREATE TABLE ... IF NOT EXISTS，内部 open_table()函数 ha_ndbcluster::get_default_num_partitions() 就会隐式调用。open_table()在某些情况下， get_default_num_partitions()在没有初始化关联thd_ndb对象的情况下调用，导致语句失败并出现 MySQL 错误 157 Could not connect to storage engine。现在 get_default_num_partitions()始终检查此thd_ndb对象是否存在，并在必要时对其进行初始化。