MySQL NDB Cluster 7.3.4 是 NDB Cluster 的新版本,基于 MySQL Server 5.6,包括
NDB
存储引擎 7.3 版的功能,并修复了以前 NDB Cluster 版本中最近发现的一些错误。
获取 MySQL NDB Cluster 7.3。 可以从https://mysql.net.cn/downloads/cluster/获得 MySQL NDB Cluster 7.3 源代码和二进制文件。
有关 MySQL NDB Cluster 7.3 中所做更改的概述,请参阅 NDB Cluster 7.3 中的新增功能。
此版本还合并了以前 NDB Cluster 版本中所做的所有错误修复和更改,以及通过 MySQL 5.6.15 在主线 MySQL 5.6 中添加的所有错误修复和功能更改(请参阅MySQL 5.6.15 中的更改(2013-12- 03,全面上市))。
打包; Solaris:ndbmtd在 Solaris 10 和 11 上的 32 位 编译
x86
,并且该二进制文件未包含在这些平台的二进制分发版中。(漏洞 #16620938)-
Microsoft Windows:内核 中用于定时调度程序事件的定时器
NDB
已经重构,部分是为了确保它们在所有平台上都是单调的。特别是,在 Windows 上,事件间隔以前是使用从中获得的值计算的GetSystemTimeAsFileTime()
,它直接从系统时间( “挂钟”)读取,并且可以任意向后或向前重置,导致错误的看门狗或心跳警报,甚至节点关闭。缺乏计时器单调性也可能导致备份和全局检查点期间的磁盘写入速度变慢。为了解决这个问题,Windows 实现现在使用QueryPerformanceCounters()
而不是GetSystemTimeAsFileTime()
. 如果在数据节点启动时未找到单调计时器,则会记录警告。此外,在所有平台上,现在会在编译时检查可用的系统单调计时器,如果找不到则构建失败;请注意, 如果后者不可用,
CLOCK_HIGHRES
现在支持作为替代方案。CLOCK_MONOTONIC
(漏洞#17647637) NDB 磁盘数据: 使用磁盘数据表和ndbmtd数据节点时,撤消缓冲区可能会过载,从而导致数据节点崩溃。使用大小约为 8K 或更大的磁盘数据列时,更有可能遇到此问题。(漏洞#16766493)
-
NDB Cluster API:
UINT_MAX64
被 Visual Studio 2010 视为有符号值。为防止这种情况发生,该值现在明确定义为无符号。(漏洞#17947674)参考资料:另请参阅:错误 #17647637。
NDB Cluster API: 一个
Ndb
对象可能在它被初始化之前接收到处理信号,导致线程交错和执行调用时可能的数据节点故障Ndb::init()
。为了防止这种情况发生,现在会在开始接收信号时进行检查,以确保在Ndb
实际处理任何信号之前对象已正确初始化。(漏洞 #17719439)NDB Cluster API: 示例 NDB API 程序文件的编译由于缺少包含指令而失败。(错误#17672846,错误#70759)
-
NDB Cluster API: 一个应用程序打开了两个不同的实例
Ndb_cluster_connection
,试图使用第二个连接对象向自身发送信号,但是这些信号被阻止,直到为该连接对象显式调用析构函数。(漏洞 #17626525)参考:这个问题是 Bug #16595838 的回归。
ndbmemcache: 运行 NDB 引擎的 memcached 服务器在与集群断开连接后可能会崩溃。(漏洞 #14055851)
MySQL NDB ClusterJ: 上一个事务失败后调用 setPartitionKey() 失败。是因为交易失败后,交易的状态没有被正确清理。此修复程序添加了该情况下所需的清理。(漏洞 #17885485)
中断外键的删除可能会导致基础表损坏。(漏洞 #18041636)
多个平台上的单调计时器可能会遇到问题,这些问题可能会导致单调时钟在时间上进行小幅回跳。这是由于多个 CPU 内核之间的时钟同步不完善,通常不会对调度程序和看门狗机制产生不利影响;因此我们通过降低反引号保护的严格程度来处理其中一些情况,尽管我们继续确保反引号小于 10 毫秒。此修复程序还删除了多项反引号检查,因此变得多余。(漏洞 #17973819)
-
在某些特定情况下,在具有两个 SQL 节点的集群中,其中一个可能挂起,并且即使在杀死mysqld进程并重新启动它 之后也无法再次访问。(错误#17875885,错误#18080104)
参考资料:另请参阅:Bug #17934985。
-
某些平台对单调计时器的支持不佳或缺乏支持会导致多线程数据节点的作业调度程序延迟信号处理的问题。现在,此类平台上的差异(计时器跳跃)的处理方式与单线程版本处理多线程数据节点进程的方式相同。(漏洞#17857442)
参考资料:另请参阅:Bug #17475425、Bug #17647637。
-
在某些情况下,
ndb_join_pushdown
启用后, 即使数据实际上并未损坏 ,也可能从 NDBCLUSTER 中获得错误Got error 290 'Corrupt key in TC, unable to xfrm' from NDBCLUSTER 。已确定列
NULL
中的 aVARCHAR
可用于构造查找键,但由于NULL
它永远不等于任何其他值,因此可以简单地消除这种查找。这种NULL
查找反过来导致了虚假的错误消息。此修复利用了这样一个事实,即键查找
NULL
永远找不到任何匹配的行,因此NDB
不会尝试执行会导致错误的查找。(漏洞 #17845161) -
本地检查点滞后看门狗跟踪使用系统调度程序执行 LCP 超时检查的次数,并使用此计数来检查超时条件,但这导致了许多问题。为了克服这些限制,LCP 看门狗已被重构以跟踪其自身的开始时间,并在每次调用时通过读取(真实)时钟来计算经过的时间。(漏洞 #17842035)
参考资料:另请参阅:错误 #17647469。
理论上,在某些情况下,
NDB
代码内部的许多输出函数可以提供未初始化的缓冲区作为输出。现在在这种情况下,将打印换行符。(错误#17775602,错误#17775772)在多线程代码中使用该
localtime()
函数会NDB
导致 ndbmtd中的其他不确定性故障。此修复替换了此函数,该函数在许多平台上使用多个线程之间共享的缓冲区,带有localtime_r()
,它可以分配给它自己的缓冲区。(漏洞 #17750252)当使用启用的单线程 ( ndbd ) 数据节点时
RealTimeScheduler
,CPU 并没有像预期的那样,每 10 毫秒暂时将其调度优先级降低到正常,以便为其他非实时线程提供运行的机会。(漏洞 #17739131)-
在仲裁员选择过程中,
QMGR
(请参阅 QMGR 块)运行一系列状态,其中前几个状态(按顺序)NULL
是 、INIT
、FIND
、PREP1
、PREP2
和START
。状态中发生了对仲裁选择超时的检查FIND
,即使在QMGR
到达PREP1
和PREP2
状态之前没有设置相应的计时器。尝试读取生成的未初始化时间戳值可能会导致 false Could not find an arbitrator, cluster is not partition-safe警告。此修复将仲裁超时计时器的设置移至
INIT
状态,以便稍后读取的值FIND
始终被初始化。(漏洞 #17738720) -
全局检查点滞后看门狗跟踪使用系统调度程序执行 GCP 滞后检查的次数,并使用此计数来检查超时条件,但这导致了许多问题。为了克服这些限制,GCP 看门狗已被重构以跟踪其自身的开始时间,并在每次调用时通过读取(真实)时钟来计算经过的时间。
此外,任何反引号(在任何情况下都很少见)现在都通过将向后时间作为新的当前时间并将这一轮的经过时间计算为 0 来处理。最后,向前跳跃的任何不良影响,可能会使立即看门狗定时器,通过从不计算比看门狗定时器请求的延迟时间长的经过时间来减少。(漏洞 #17647469)
参考资料:另请参阅:错误 #17842035。
GCP_COMMIT
当 GCP 进度看门狗未检测到全局检查点中的进度时, 警告之间的间隔长度(预期为 10 秒)并不总是正确计算。(漏洞 #17647213)尝试删除外键约束使用的索引导致数据节点失败。现在在这种情况下,用于执行删除的语句会失败。(漏洞 #17591531)
-
在极少数情况下,在事务提交时,
Ndb
对象在事务协调器(DBTC
内核块)发送预期COMMIT_CONF
信号之前被释放;NDB
未能发送COMMIT_ACK
响应信号,导致NDB
内核内存泄漏,随后可能导致节点故障。现在直到实际收到信号
Ndb
后才会释放对象 。COMMIT_CONF
(漏洞#16944817) 在对表进行查询时失去与管理节点或数据节点的连接会
ndbinfo.memoryusage
导致发出查询的 SQL 节点失败。(错误#14483440,错误#16810415)ndbd_redo_log_reader实用程序现在支持一个
--help
选项。使用此选项会导致程序打印基本使用信息,然后退出。(缺陷 #11749591,缺陷 #36805)