MySQL NDB Cluster 7.6.1 是 NDB 7.6 的新版本,它基于 MySQL Server 5.7,包括
NDB
存储引擎 7.6 版中的功能,并修复了最近在以前的 NDB Cluster 版本中发现的错误。
获取 NDB Cluster 7.6。 NDB Cluster 7.6.1 只是一个内部测试版本,没有向公众发布。
有关 NDB Cluster 7.6 中所做更改的概述,请参阅 NDB Cluster 中的新增功能。
此版本还合并了以前 NDB Cluster 版本中所做的所有错误修复和更改,以及通过 MySQL 5.7.17 在主线 MySQL 5.7 中添加的所有错误修复和功能更改(请参阅MySQL 5.7.17 中的更改(2016-12- 12、普遍适用))。
-
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_ACK
和TC_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在主线程以外的任何线程中接收到信号时,不会写入任何跟踪,因为所有信号都被其他线程阻塞了。通过从被阻止的信号列表中删除
SIGBUS
、SIGFPE
、SIGILL
和 信号来解决此问题。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
--port
option (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。