Documentation Home
MySQL NDB Cluster 7.5 发行说明  /  MySQL NDB Cluster 7.5.5 (5.7.17-ndb-7.5.5) 的变化(2017-01-17,全面上市)

MySQL NDB Cluster 7.5.5 (5.7.17-ndb-7.5.5) 的变化(2017-01-17,全面上市)

MySQL NDB Cluster 7.5.5 是 MySQL NDB Cluster 7.5 的新版本,它基于 MySQL Server 5.7,包括NDB存储引擎 7.5 版中的功能,并修复了最近在以前的 NDB Cluster 版本中发现的错误。

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

有关 MySQL NDB Cluster 7.5 中所做更改的概述,请参阅 NDB Cluster 7.5 中的新增功能

此版本还合并了以前 NDB Cluster 版本中所做的所有错误修复和更改,以及通过 MySQL 5.7.17 在主线 MySQL 5.7 中添加的所有错误修复和功能更改(请参阅MySQL 5.7.17 中的更改(2016-12- 12、普遍适用))。

修正错误

  • 打包: SLES 12 的 NDB Cluster Auto-Installer RPM 包由于依赖python2-crypto而不是 python-pycrypto. (缺陷号 25399608)

  • 打包: MySQL NDB Cluster 包的 RPM 安装 auto-installer程序依赖于 python2-crypt而不是 python-crypt. (漏洞#24924607)

  • Microsoft Windows: 当自动安装程序 ( ndb_setup.py ) 在使用瑞典语作为系统语言的 Windows 主机上运行时,安装失败。cp1252这是由于使用字符集发出的系统消息 当这些消息包含未直接映射到 7 位 ASCII 的字符(例如 中的ä字符 Tjänsten ... startar)时,转换为 UTF-8自动安装程序 Web 客户端所预期的那样)失败。

    此修复仅在瑞典语作为系统语言的情况下进行了测试,但应该适用于设置为使用该cp1252 字符集的其他欧洲语言的 Windows 系统。(漏洞 #83870,漏洞 #25111830)

  • ndbinfo 信息数据库:ndbinfo由于手动复制源中的表和视图定义, 出现了一些关于表的不一致和其他问题现在生成了这些的 SQL 语句,以保持一致性。(缺陷号 23305078)

    参考资料:另请参阅:Bug #25047951。

  • ndb_restore没有正确恢复超过 341 列的表。这是因为用于保存从 .ctl文件中读取的表元数据的缓冲区大小不足,因此在这种情况下只能从中读取部分表描述符。此问题已通过增加ndb_restore用于文件读取的缓冲区大小来解决。(缺陷号 25182956)

    参考资料:另请参阅:Bug #25302901。

  • ndbmtd在主线程以外的任何线程中接收到信号时,不会写入任何跟踪,因为所有信号都被其他线程阻塞了。通过从被阻止的信号列表中删除SIGBUSSIGFPESIGILL和 信号来解决此问题。SIGSEGV(缺陷号 25103068)

  • CMake现在避免 -fexpensive-optimizations为 GCC 版本配置选项,该选项会触发错误的移位或优化。(漏洞 #24947597,漏洞 #83517)

  • 该函数用于生成唯一的表 ID 和表版本,以识别分布在多个 SQL 节点之间的模式操作,依赖于永远不会在两个不同的 mysqld 实例上生成相同数字rand()的假设。rand()后来确定情况并非如此,实际上很可能在所有 SQL 节点上产生相同的随机数。

    此修复删除了rand()用于生成唯一表 ID 或版本的用法,而是将序列与协调器的节点 ID 结合使用。这保证了序列计数器回绕之前的唯一性,这对于此目的应该足够了。

    当同时或几乎同时重新启动多个 mysqld进程时,或者在多个 SQL 节点上发出相同的or语句时, 可以在日志中观察到这种重复的影响(例如NDB create db: waiting max 119 sec for distribution )。(漏洞 #24926009)CREATE DATABASEDROP DATABASE

  • ndb_show_tables实用程序不显示哈希映射或完全复制的触发器的类型信息。(漏洞 #24383742)

  • 触发即时触发器时,长消息缓冲区耗尽可能会导致行 ID 泄漏;这可能会在以后导致持久的RowId already allocated错误(NDB错误 899)。(漏洞 #23723110)

    参考资料:另请参阅:Bug #19506859、Bug #13927679。

  • NDB Cluster Auto-Installer 没有向用户展示如何强制退出应用程序 ( CTRL + C )。(缺陷 #84235,缺陷 #25268310)

  • NDB Cluster Auto-Installer 在无法启动相关服务时无法退出。(错误#84234,错误#25268278)

  • The NDB Cluster Auto-Installer failed when the port specified by the --portoption (or the default port 8081) was already in use. 现在在这种情况下,当所需的端口不可用时,将依次测试接下来的 20 个端口,并使用第一个可用的端口;只有当所有这些都在使用时,自动安装程序才会失败。(缺陷 #84233,缺陷 #25268221)

  • 未检测到 NDB Cluster Auto-Installer 的多个实例。这可能会导致无意中在同一主机上进行多次部署、杂散进程和类似问题。此问题已通过让自动安装程序创建一个 PID 文件 ( mcc.pid) 来解决,该文件在成功退出后将被删除。(漏洞 #84232,漏洞 #25268121)

  • 当更新外键关系中的父NDB表时,更新会按预期级联到子表,但更改不会级联到该子表的子表(即原始父表的孙表)。这可以使用由以下CREATE TABLE语句生成的表来说明:

    CREATE TABLE parent(
      id INT PRIMARY KEY AUTO_INCREMENT,
      col1 INT UNIQUE,
      col2 INT
    ) ENGINE NDB;
    
    CREATE TABLE child(
      ref1 INT UNIQUE,
      FOREIGN KEY fk1(ref1)
        REFERENCES parent(col1) ON UPDATE CASCADE
    ) ENGINE NDB;
    
    CREATE TABLE grandchild(
      ref2 INT,
      FOREIGN KEY fk2(ref2)
        REFERENCES child(ref1) ON UPDATE CASCADE
    ) ENGINE NDB;

    child是表的孩子 parent;tablegrandchild 是 table 的子项child,是 的孙项parent。在这种情况下,对列col1的更改parent 级联到ref1表中 child,但它并不总是依次传播到ref2表中 grandchild。(缺陷 #83743,缺陷 #25063506)

  • 二进制日志注入器NDB线程使用注入器互斥锁来执行两个重要任务:

    1. 防止客户端线程在注入器线程等待时创建或删除事件 pollEvents()

    2. 维护对注入器线程与客户端线程共享的数据的访问。

    其中第一个可以长时间保持互斥量(大约 10 毫秒),同时非常快地再次锁定它。这可以防止它在不必要的很长一段时间内获得数据访问锁(饥饿)。

    为了解决这些问题,注入器互斥锁被重构为两个——一个来处理刚刚列出的两个任务中的每一个。

    还发现 binlog 注入器线程的初始化在几个地方不必要地持有注入器互斥锁,当只有本地线程数据被初始化并发送带有条件信息的信号时没有等待更新。这些不需要的操作已被删除,连同之前针对相关注入器互斥锁不足问题的许多临时修复程序。(错误#83676、错误#83127、错误#25042101、错误#24715897)

    参考资料:另请参阅:Bug #82680、Bug #20957068、Bug #24496910。

  • StopOnError设置为 0 运行的数据节点经历意外关闭时,自动重启执行与前一个相同类型的启动。在数据节点之前已使用该 --initial选项启动的情况下,这意味着执行了初始启动,这在多个数据节点故障的情况下可能会导致数据丢失。每当数据节点关闭导致生成核心转储时,也会发生此问题。现在执行检查以捕获所有此类情况,并改为执行正常重启。

    此外,如果发生故障的数据节点在关闭之前无法向天使进程发送启动阶段信息,则关闭始终被视为启动失败,也会导致初始重启。通过添加检查以仅在从客户端接收到有效启动阶段时才执行启动失败处理来解决此问题。(缺陷 #83510,缺陷 #24945638)

  • ndbmtd使用 GNU 工具 5.3 版在 Solaris/SPARC 上构建时,使用生成的二进制文件的数据节点在启动期间失败。(漏洞 #83500,漏洞 #24941880)

    参考资料:另请参阅:Bug #83517、Bug #24947597。

  • MySQL NDB Cluster 无法使用 GCC 6 进行编译。(Bug #83308,Bug #24822203)

  • 数据节点重启时,先停止节点,然后经过固定的等待,管理服务器认为节点已经进入NOT_STARTED状态,此时向节点发送启动信号。如果节点因为尚未完成停止(因此实际上不在)而未就绪NOT_STARTED,则该信号将被静默忽略。

    为了解决这个问题,管理服务器现在检查数据节点在发送开始信号之前是否实际上已经达到 NOT_STARTED 状态。等待节点达到此状态分为两个独立的检查:

    • 等待数据节点开始关闭(最多 12 秒)

    • 等待数据节点完成关闭并达到 NOT_STARTED状态(最长 120 秒)

    如果其中任何一种情况超时,则重启被视为失败,并返回相应的错误。(错误#49464,错误#11757421)

    参考资料:另请参阅:Bug #28728485。