Documentation Home
MySQL NDB Cluster 7.6 发行说明  / 发布系列变更日志:MySQL NDB Cluster 7.6  /  MySQL NDB Cluster 7.6.1 (5.7.17-ndb-7.6.1) 的变化(未发布,开发里程碑 1)

MySQL NDB Cluster 7.6.1 (5.7.17-ndb-7.6.1) 的变化(未发布,开发里程碑 1)

添加或更改的功能

  • NDB 磁盘数据: 此版本中为 NDB 磁盘数据表引入了一种新的文件格式。新格式提供了一种机制,可以在不重复使用表 ID 的情况下唯一标识每个磁盘数据表。这旨在帮助解决页面和范围处理问题,这些问题对用户来说是快速创建和删除磁盘数据表的问题,而旧格式没有提供现成的修复方法。

    每当创建新的撤消日志文件组和表空间数据文件时,都会使用新格式。与现有磁盘数据表相关的文件继续使用旧格式,直到重新创建它们的表空间和撤消日志文件组。 重要提示:新旧格式不兼容,因此不能用于不同的数据文件或由同一磁盘数据表或表空间使用的撤消日志文件。

    为避免与旧格式相关的问题,您应该在升级时重新创建任何现有的表空间和撤消日志文件组。--initial作为升级过程的一部分,您可以通过执行每个数据节点的初始重启(即使用该 选项)来完成此操作。由于当前版本是 pre-GA Developer 版本,此初始节点重启目前是可选的,但 您应该期望它 - 并立即做好准备 - 在 NDB 7.6 的 GA 版本中是强制性的

    如果您正在使用磁盘数据表,从 任何NDB 7.6 版本降级到任何 NDB 7.5 或更早版本需要重新启动数据节点 --initial作为降级过程的一部分,因为 NDB 7.5 和更早版本无法读取新的磁盘数据文件格式。

    有关更多信息,请参阅 升级和降级 NDB Cluster

修正错误

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

  • NDB 磁盘数据: 已删除的 NDB 磁盘数据表中的陈旧数据可能会包含在备份中,因为已为这些数据启用了磁盘扫描。为了防止这种可能性,现在在进行备份时禁用磁盘扫描(与其他类型的扫描一样)。(漏洞 #84422,漏洞 #25353234)

  • NDB Cluster API: 当客户端进程正在接收诸如SUB_GCP_COMPLETE_ACKTC_COMMIT_ACK时,这些信号会临时缓冲在发送它们的客户端的发送缓冲区中。如果没有显式刷新,信号将保留在这些缓冲区中,直到客户端再次醒来并刷新其缓冲区。因为没有尝试对信号在本地客户端缓冲区中保持未发送的时间施加上限,这可能会导致等待这些信号的组件发生超时和其他不当行为。

    此外,对先前相关问题的修复可能会通过删除客户端唤醒而使这种情况变得更糟,在此期间客户端发送缓冲区可能已被刷新。

    当前的修复将刷新接收者发送的消息的责任转移到了接收者(poll_owner 客户端)。这意味着不再需要唤醒所有客户端只是为了让它们刷新缓冲区。取而代之的是,poll_owner客户端(已经在运行)在向接收者传递信号时刷新发送缓冲区。(漏洞 #22705935)

    参考资料:另请参阅:Bug #18753341、Bug #23202735。

  • NDB Cluster APIs: 自适应发送算法没有按预期使用,导致每个执行请求都 NDB立即发送到内核,而不是先尝试将多个请求收集到更大的块中再发送。这招致了大约 10% 的性能损失。该问题是由于传输层始终将forceSend多个 API 方法(包括 nextResult()close())中使用的参数处理为true. (缺陷 #82738,缺陷 #24526123)

  • 当备份包含一个包含超过 500 列的表时,ndb_print_backup_file实用程序在尝试从备份文件中读取时失败。(漏洞 #25302901)

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

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

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

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

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

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

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

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

  • 当重做日志耗尽时关闭的数据节点在重新启动时不会自动触发本地检查点,需要使用DUMP 7099手动启动一个。(漏洞 #82469,漏洞 #24412033)

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

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

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

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

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

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