MySQL NDB Cluster 7.4.1 是 NDB Cluster 的新开发者里程碑版本,它基于 MySQL Server 5.6 并预览了正在为
NDB存储引擎 7.4 版开发的新功能。
获取 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.20 在主线 MySQL 5.6 中添加的所有错误修复和功能更改(请参阅MySQL 5.6.20 中的更改(2014-07- 31,一般可用性))。
-
NDB 复制: 对用于 MySQL NDB 集群复制冲突检测和解决的异常表进行了许多更改和改进。保留的列名命名空间现在用于元列,它允许记录不属于表主键的主表列的任意子集。异常表中所有元列的名称现在应以 . 为前缀
NDB$。不再需要记录完整的主键。主表列与异常表列的匹配现在仅根据名称和类型执行。此外,您现在可以在例外表中记录不属于主表主键的列的值。
现在可以在冲突例外表中使用预定义的可选列来获取有关冲突类型、原因和原始交易的信息。
现在支持读取跟踪——即检测一个集群中给定行的读取与另一个集群中同一行的更新或删除之间的冲突。
ndb_log_exclusive_reads这需要在slave集群上设置等于1获得独占读锁 。冲突读取读取的所有行都记录在异常表中。有关更多信息和示例,请参阅 读取冲突检测和解决。继续支持现有的例外表。有关其他信息,请参阅 冲突解决例外表。
-
性能: 在节点启动和重启方面进行了许多性能和其他改进。以下列表包含对这些更改中每一项的简要说明:
在启动时分配的内存可以使用之前,它必须被触及,导致操作系统分配实际需要的物理内存。触摸分配的每一页内存的过程现在已经是多线程的,当由 16 个线程执行时,触摸时间比单线程短 3 倍。
在执行节点或系统重启时,需要恢复分片的本地检查点。这个过程以前在一个被发现对性能至关重要的点使用延迟信号;这些现在已被正常(未延迟)信号所取代,这将大大缩短备份 MySQL NDB Cluster 或从备份中恢复所需的时间。
-
以前,在任何给定时间最多可能有 2 个 LDM 实例在本地检查点处于活动状态。现在,多达 16 个 LDM 可用于执行此任务,这提高了可用 CPU 功率的利用率,并可将 LCP 速度提高 10 倍,从而大大缩短重启时间。
更好地报告磁盘写入和加强对这些写入的控制也构成了这项工作的很大一部分。新
ndbinfo表disk_write_speed_base、disk_write_speed_aggregate和disk_write_speed_aggregate_node提供有关每个正在使用的 LDM 线程的磁盘写入速度的信息。和 配置参数已被弃用,并在未来的 MySQL NDB Cluster 版本中被删除DiskCheckpointSpeed。DiskCheckpointSpeedInRestart此版本添加了数据节点配置参数MinDiskWriteSpeed、MaxDiskWriteSpeed、MaxDiskWriteSpeedOtherNodeRestart和MaxDiskWriteSpeedOwnRestart当当前节点、另一个节点或没有节点当前正在重新启动时,控制 LCP 和备份的写入速度。有关更多信息,请参阅
ndbinfo前面命名的表和 MySQL NDB Cluster 配置参数的描述。 改进了 MySQL NDB Cluster 启动阶段的报告,打印输出更频繁。源和文档中还提供了有关启动阶段及其实施的新的更好的信息。请参阅 NDB Cluster 启动阶段摘要。
-
NDB 复制: 当使用循环或 “主动-主动” MySQL NDB 集群复制设置进行冲突检测和解决时,现在可以通过设置
ndb_slave_conflict_role此版本中引入的服务器系统变量. 此变量可以采用 、 、 或(默认值)中的PRIMARY任何SECONDARY一个PASS值NULL。(PASS启用忽略任何冲突解决功能的影响的直通状态。)当需要从充当主节点的 MySQL NDB Cluster 进行故障转移时,这可能很有用。当该变量的值改变时,必须停止从 SQL 线程。此外,不能直接在
PASS或PRIMARY之间更改它SECONDARY。有关详细信息,请参阅 NDB Cluster Replication Conflict Resolution
ndb_slave_conflict_role的 说明。
性能:优化了 几个与接收线程相关的内部方法
NDB,使 mysqldNDB使用存储引擎更高效地处理 SQL 应用程序特别是,这项工作提高了该方法的性能,该NdbReceiver::execTRANSID_AI()方法通常用于从数据节点接收记录作为扫描操作的一部分。(由于接收器线程有时每秒必须处理数百万条接收到的记录,因此此方法不执行不必要的工作或占用并非严格需要的资源是至关重要的。)相关的内部功能receive_ndb_packed_record()和handleReceivedSignal()方法也得到了改进,并变得更加有效。
现在可以从此
memory_per_fragment版本中添加到ndbinfo信息数据库的视图中获取有关各个片段的内存使用情况的信息。此信息包括具有固定和可变元素大小的页面、行、固定元素空闲槽、可变元素空闲字节和散列索引内存使用情况。有关信息,请参阅 ndbinfo memory_per_fragment 表。
NDB Cluster API: 当 NDB API 客户端应用程序收到带有无效块或信号编号的信号时,
NDB仅提供一条非常简短的错误消息,无法准确传达问题的性质。现在在这种情况下,当检测到不良信号或消息时会提供适当的打印输出。此外,现在检查消息长度以确保它与嵌入信号的大小相匹配。(漏洞 #18426180)在某些情况下,传输器接收缓冲区在被另一个线程读取时被一个线程重置。当一个线程接收数据和另一个线程启动传输器断开连接(断开连接清除此缓冲区)之间发生竞争条件时,就会发生这种情况。现在已实施并发逻辑以防止发生这种竞争。(缺陷 #19552283,缺陷 #73790)
-
当一个新的数据节点启动时,API 节点被允许在数据节点准备好之前尝试向数据节点注册自己以执行事务。这迫使 API 节点在重试之前等待额外的心跳间隔。
为了解决这个问题, 在此期间可能发出 的一些HA_ERR_NO_CONNECTION错误(错误 4009)已更改为集群暂时不可用错误(错误 4035),这应该允许 API 节点比以前更快地使用新数据节点。作为此修复的一部分,一些错误分类的错误已移至正确的类别中,一些不再使用的错误已被删除。(缺陷 #19524096,缺陷 #73758)
-
ALTER TABLE ... REORGANIZE PARTITION将集群中的数据节点数量从 4 个增加到 16 个后 执行 导致数据节点崩溃。此问题显示为由先前的修复引起的回归,该修复使用已在使用的转储代码 (7019) 添加了新的转储处理程序,这导致命令执行两个具有不同语义的不同处理程序。新处理程序被分配了一个新DUMP代码 (7024)。(漏洞#18550318)参考:这个问题是 Bug #14220269 的回归。
当某些查询在节点故障之前生成的信号具有超过 18 个数据字时,此类信号未正确写入跟踪文件中。(漏洞 #18419554)
在中等流量下,在将ndbmtd与多个 TC 线程一起 使用时,多个节点的故障 没有得到妥善处理,这在某些情况下可能导致集群意外关闭。(错误号 18069334)
对于多线程数据节点,一些线程确实经常通信,结果是非常旧的信号可以保留在信号缓冲区的顶部。在执行线程跟踪时,信号转储程序根据它在信号缓冲区中找到的内容计算出最新的信号 ID,这意味着这些旧信号可能会被错误地计为最新信号。现在,信号 ID 计数器保留为线程状态的一部分,在为跟踪文件转储信号时使用的正是这个值。(错误#73842,错误#19582807)