Documentation Home
MySQL NDB Cluster 7.4 发行说明
MySQL NDB Cluster 7.4 发行说明  / 发布系列变更日志：MySQL NDB Cluster 7.4  /  MySQL NDB Cluster 7.4.1 (5.6.20-ndb-7.4.1) 的变化 (2014-09-25, 发展里程碑)

MySQL NDB Cluster 7.4.1 (5.6.20-ndb-7.4.1) 的变化 (2014-09-25, 发展里程碑)

节点重启性能和报告增强

  • 性能： 在节点启动和重启方面进行了许多性能和其他改进。以下列表包含对这些更改中每一项的简要说明：

    • 在启动时分配的内存可以使用之前，它必须被触及，导致操作系统分配实际需要的物理内存。触摸分配的每一页内存的过程现在已经是多线程的，当由 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 启动阶段摘要。

改进的扫描和 SQL 处理

  • 性能：优化了 几个与接收线程相关的内部方法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）