MySQL NDB Cluster 7.4.16 是 MySQL NDB Cluster 7.4 的新版本,它基于 MySQL Server 5.6,包括NDB
存储引擎 7.4 版中的功能,并修复了最近在以前的 NDB Cluster 版本中发现的错误。
获取 MySQL NDB Cluster 7.4。 MySQL NDB Cluster 7.4 源代码和二进制文件可以从https://mysql.net.cn/downloads/cluster/获得。
有关 MySQL NDB Cluster 7.4 中所做更改的概述,请参阅 NDB Cluster 7.4 中的新增功能。
此版本还合并了以前 NDB Cluster 版本中所做的所有错误修复和更改,以及通过 MySQL 5.6.37 在主线 MySQL 5.6 中添加的所有错误修复和功能更改(请参阅MySQL 5.6.37 中的更改(2017-07- 17, 一般可用性) )。
重要变更;MySQL NDB ClusterJ: NDB Cluster 不再支持 OpenJPA 的 ClusterJPA 插件,并且已从发行版中删除。(缺陷号 23563810)
NDB 复制: 添加了 mysqld
--ndb-log-update-minimal
日志记录选项。此选项导致仅将主键值写入前映像,并且仅在后映像中更改列。(缺陷号 24438868)添加了ndb_config
--diff-default
的 选项。此选项使程序仅打印那些具有不同于默认值的参数。(缺陷 #85831,缺陷 #25844166)向ndb_config 添加了
--query-all
选项。此选项的行为与 选项非常相似,只是 (缩写形式:)一次转储所有属性的配置信息。(缺陷 #60095,缺陷 #11766869)--query
--query-all
-a
NDB 复制: 添加了一个检查以在检测到配置为多线程从属时停止
NDB
复制从属(例如,如果slave_parallel_workers
设置为非零值)。(缺陷号 21074209)NDB Cluster APIs: 实现方法
NdbDictionary::NdbTableImpl::getColumn()
,在 NDB API 的许多地方使用,其中列按名称引用,已变得更加高效。此方法使用列数组的线性搜索来查找正确的列对象,这对于包含许多列的表可能效率低下,并被检测为客户应用程序中 CPU 的大量使用。(理想情况下,用户应该执行名称到列对象的映射,然后在方法调用中使用列 ID 或对象,但实际上并不总是这样做。)以前用于名称查找的成本较低的哈希索引实现是恢复具有相对多列的表。(线性搜索继续用于具有较少列的表,其中性能差异可以忽略不计。MySQL NDB ClusterJ: 运行 ClusterJ 的单元测试时,跳过了 JTie 和 NDB JTie 测试。(缺陷号 26088583)
MySQL NDB ClusterJ:NDB JTie 测试编译失败。这是由于空引用的处理方式所致,已通过此修复程序得到纠正。(缺陷号 26080804)
.log
由于过滤掉同一节点组中其他节点记录的更改的问题, 备份文件包含一个或多个额外片段的日志条目。这导致.log
文件更大,因此使用了比必要更多的资源;它还可能在恢复时引起问题,因为在应用日志时来自不同节点的备份可能会相互干扰。(缺陷号 25891014)当对重做日志文件进行最终写入时,预计下一个日志文件已经打开用于写入,但磁盘速度较慢时情况并非总是如此,从而导致节点故障。现在在这种情况下
NDB
等待下一个文件在尝试写入之前正确打开。(缺陷号 25806659)数据节点线程可以绑定到单个 CPU 或一组 CPU,一组 CPU 在内部表示
NDB
为SparseBitmask
. 尝试锁定一组 CPU 时,CPU 使用率过高,因为执行锁定的例程使用了该方法,该方法查找在 (2 32 -2,或 4294967294mt_thr_config.cpp::do_bind()
) 的整个理论范围内设置的位). 这是通过使用 修复的,它可用于仅迭代实际设置的那些位。(漏洞#25799506)SparseBitmask
SparseBitmask::getBitNo()
-
批量更新是通过读取记录并在记录集上执行事务来执行的,该事务在读取记录时启动。当事务初始化失败时,事务执行器函数随后没有意识到发生了这种情况,从而导致 SQL 节点故障。通过在尝试初始化事务时提供适当的错误处理来解决此问题。(缺陷号 25476474)
参考资料:另请参阅:Bug #20092754。
设置
NoOfFragmentLogParts
为每个本地数据管理器有超过 4 个重做日志部分会导致资源耗尽和随后的多个数据节点故障。由于这是一个无效的配置,因此添加了一个检查来检测每个 LDM 具有超过 4 个重做日志部分的配置,并将其视为无效而拒绝。(缺陷号 25333414)对主键大于80字节的表 执行在线
ALTER TABLE ... REORGANIZE PARTITION
语句 导致数据节点重启,导致重组失败。NDB
(漏洞#25152165)-
当外键触发器列与触发器执行期间提供给它们的值不匹配时,会引发错误 240,但没有错误消息指示问题的来源。(漏洞 #23141739)
参考资料:另请参阅:Bug #23068914、Bug #85857。
-
如果 LDM 块的数量不能被 TC/SPJ 块的数量整除,则 SPJ 请求不会平均分布在可用的 SPJ 实例上。现在,循环分配用于更有效地在所有可用的 SPJ 实例之间分配 SPJ 请求。
作为这项工作的一部分,一些未使用的成员变量已从类中删除
Dbtc
。(漏洞 #22627519) ALTER TABLE .. MAX_ROWS=0
现在只能通过使用复制ALTER TABLE
语句来执行。MAX_ROWS
不能再使用ALGORITHM=INPLACE
或ONLINE
关键字执行重置 为 0。(缺陷号 21960004)在系统重新启动期间,当一个节点因未发送心跳而发生故障时,所有其他节点仅报告另一个节点发生故障而没有任何其他信息。现在在这种情况下,错误日志和数据节点日志都会报告心跳丢失的事实以及发送心跳失败的节点的 ID。(缺陷号 21576576)
计划关闭具有超过 10 个数据节点的 NDB Cluster 并不总是正常执行。(缺陷号 20607730)
由于之前的问题,当查询涉及 a 时,优化和执行阶段之间的分离不明确
GROUP BY
,join-pushable 评估器不确定其优化的查询执行计划是否实际上是可推送的。出于这个原因,这样的分组连接总是被认为是不可推送的。已确定分离问题已通过 MySQL 5.6 中已完成的工作得到解决,因此我们现在删除此限制。(漏洞 #86623,漏洞 #26239591)-
当删除表中的所有行后紧跟 时
DROP TABLE
,可能DBACC
哈希索引的收缩在删除之前尚未准备好。这种收缩是一个不检查表状态的每个片段操作。当一个表被drop时,DBACC
释放资源,期间分片大小和页目录的描述不一致;这可能会导致读取陈旧页面和未定义的行为。由于散列索引的扩展,插入大量行然后删除表也应该有这样的效果。
为了解决这个问题,我们确保当一个片段即将被释放时,这个片段上没有挂起的扩展或收缩操作。(错误#86449,错误#26138592)
内部函数从信号
execute_signals()
中mt.cpp
读取三个部分指针,即使没有传递给它。这基本上是无害的,尽管没有必要。当读取的信号是作业缓冲区最后一页上的最后一个信号时,并且内存中的下一页未映射或无法访问时, ndbmtd失败并出现错误。为了防止这种情况发生,该函数现在只读取实际传递给它的节指针。(漏洞 #86354,漏洞 #26092639)ndb_show_tables程序 选项在设置为 0(假)时无法正常工作;
--unqualified
这应该禁用该选项,从而导致在输出中打印完全限定的表名和索引名。(漏洞 #86017,漏洞 #25923164)当
NDB
创建带有外键约束的表时,首先创建其索引,然后在创建外键时,将这些索引加载到NDB
字典缓存中。当CREATE TABLE
语句由于与外键相关的问题而失败时,缓存中已有的索引不会失效。这意味着任何CREATE TABLE
具有与失败语句中的名称相同的索引的后续结果都会产生不一致的结果。现在,在这种情况下,任何以 failed 命名的索引都会CREATE TABLE
立即从缓存中失效。(缺陷 #85917,缺陷 #25882950)当要添加的键具有同一个表上现有外键的名称时尝试执行
ALTER TABLE ... ADD FOREIGN KEY
失败,并显示错误消息。(漏洞 #85857,漏洞 #23068914)-
节点内部调度程序(在 中
mt.cpp
)收集关于它自己的进度和它正在执行的任何未完成工作的统计信息。其中一项统计数据是未完成的发送字节数,收集在send_buffer::m_node_total_send_buffer_size
. 此信息稍后可能会被发送线程调度程序使用,发送线程调度程序将其用作调整其自身发送性能与延迟的指标。为了减少内部发送缓冲区上的锁争用,它们被分成两
thr_send_buffer
部分,m_buffer
和m_sending
,每个部分都由自己的互斥体保护,它们的组合大小由 表示m_node_total_send_buffer_size
。对代码的调查表明,对于使用哪个互斥量更新 没有一致性,
m_node_total_send_buffer_size
结果是没有对该值的并发保护。为避免这种情况,m_node_total_send_buffer_size
被替换为两个值m_buffered_size
和m_sending_size
,它们分别跟踪两个缓冲区的大小。这些计数器在分别保护每个缓冲区的两个不同互斥锁的保护下更新,现在加在一起以获得总大小。建立并发控制后,部分计数的更新现在应该是正确的,以便它们的组合值不再随着时间的推移累积错误。(缺陷 #85687,缺陷 #25800933)
-
使用长信号格式的丢弃
TRANS_AI
信号未由DBTC
内核块处理。(缺陷 #85606,缺陷 #25777337)参考资料:另请参阅:Bug #85519、Bug #27540805。
-
为了防止扫描返回比客户端保留缓冲区更多的行、字节或两者,
DBTUP
内核块 在发送给请求 块TRANSID_AI
的信号中报告它已发送给客户端 的大小。知道可用于结果集的最大批处理大小,如果超过,则终止扫描批处理。TUPKEYCONF
DBLQH
DBLQH
该
DBSPJ
块的FLUSH_AI
属性允许从同一行DBTUP
生成两个TRANSID_AI
结果,一个用于客户端,一个用于DBSPJ
,这是在连接表上进行键查找所需要的。这两个的大小都被添加到DBTUP
块报告的读取长度中,这导致控制DBLQH
块认为它消耗了比实际情况更多的可用最大批大小,从而导致扫描批提前终止,这可能对 SPJ 扫描的性能产生负面影响。为更正此问题,在这种情况下,现在仅报告 API 请求的实际读取长度部分。(缺陷 #85408,缺陷 #25702850) 使用 gcc版本 6.0.0 或更高版本编译 NDB 内核时,现在使用
-flifetime-dse=1
. (缺陷 #85381,缺陷 #25690926)