Documentation Home
MySQL NDB Cluster 7.3 发行说明
MySQL NDB Cluster 7.3 发行说明  /  MySQL NDB Cluster 7.3.5 (5.6.17-ndb-7.3.5) 的变化（2014-04-07，全面上市）

MySQL NDB Cluster 7.3.5 (5.6.17-ndb-7.3.5) 的变化（2014-04-07，全面上市）

MySQL NDB Cluster 7.3.5 是 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.17 在主线 MySQL 5.6 中添加的所有错误修复和功能更改（请参阅MySQL 5.6.17 中的更改（2014-03- 27，一般可用性））。

添加或更改的功能

  • 对短缺和统计数据的处理 LongMessageBuffer 已改进如下：

    • 的默认值LongMessageBuffer 已从 4 MB 增加到 64 MB。

    • 当此资源耗尽时，现在会在数据节点日志中打印一条合适的信息性消息，描述问题的可能原因并提出可能的解决方案。

    • LongMessageBuffer使用信息现在显示在 ndbinfo.memoryusage表中。有关示例和其他信息，请参阅此表的说明。

修正错误

  • 重要更改： 服务器系统变量 ndb_index_cache_entries和 ndb_index_stat_freq，在以前的 MySQL NDB Cluster 版本系列中已被弃用，现在已被删除。（错误#11746486，错误#26673）

  • 复制： 日志轮换事件可能导致 group_relay_log_pos在组内错误地向前移动。这意味着，当事务被重试时，或者如果 SQL 线程在一个或多个日志轮换后的事务中间停止（例如事务或组跨越多个中继日志文件），部分或全部组是默默跳过。

    此问题已通过更正用于在更新日志位置作为中继日志轮换的一部分时避免触及 SQL 线程的坐标的逻辑中的问题得到解决，从而可以在不使用多线程从属时更新 SQL 线程的坐标，即使在一群人中间。（漏洞#18482854）

  • Solaris： 在为 Solaris 平台编译 MySQL NDB Cluster 软件时发现的一个问题可能会导致 ThreadConfig在此类系统上使用时出现问题。（漏洞 #18181656）

  • NDB Replication： MySQL NDB Cluster Replication 中的一个 slave 现在监视从其直接上游 master 接收的纪元号的进展，这既可以作为对复制低级功能的有用检查，也可以在事件复制时提供警告在已经应用的位置意外重新启动。

    作为此增强功能的结果，epoch ID 冲突会产生以下结果，具体取决于从属 SQL 线程的状态：

    • 在RESET SLAVE 语句之后，不采取任何操作，以便在没有虚假警告的情况下执行该语句。

    • 在 之后START SLAVE，会产生一个警告，表明从站正被定位在一个已经应用的时代。

    • 在所有其他情况下，从属 SQL 线程将停止，以防止系统故障导致重新应用现有纪元的可能性。

    （漏洞#17461576）

    参考资料：另请参阅：错误 #17369118。

  • NDB Cluster API： 当 NDB API 客户端应用程序收到带有无效块或信号编号的信号时，NDB 仅提供一条非常简短的错误消息，无法准确传达问题的性质。现在在这种情况下，当检测到不良信号或消息时会提供适当的打印输出。此外，现在检查消息长度以确保它与嵌入信号的大小相匹配。（漏洞 #18426180）

  • NDB Cluster API： 在 MySQL NDB Cluster 7.3.4 中执行的重构无意中引入了 Ndb.hpp对未包含在分发中的文件的依赖性，这导致 NDB API 应用程序无法编译。依赖关系已被删除。（缺陷 #18293112，缺陷 #71803）

    参考：这个问题是 Bug #17647637 的回归。

  • NDB Cluster APIs： NDB API 应用程序向数据节点发送扫描查询；扫描由事务协调器 (TC) 处理。TC 将请求转发在指定的时限内LQHKEYREQ未收到响应，则中止事务LQHKEYCONF事务成功中止后，TC 向TCROLLBACKREPNDBAPI 客户端发送一个消息，NDB API 客户端通过清除Ndb与事务关联的任何对象来处理此消息。

    客户端以信号的形式接收它请求的TRANSID_AI数据，在数据节点缓冲以发送，并且可以在延迟后传送。收到这样的信号后，NDB检查交易状态和 ID：如果符合预期，它会使用Ndb与该交易关联的对象来处理信号。

    当满足以下所有条件时，会出现当前错误：

    • 事务协调器由于延迟而中止事务并向TCROLLBACPREP客户端发送信号，同时将 TRANSID_AI已在 LDM 处缓冲以供交付的 a 交付给同一客户端。

    • NDB API 客户端在收到TCROLLBACKREP信号后认为交易完成，并立即关闭交易。

    • 客户端有一个单独的接收线程与参与关闭事务的线程同时运行。

    • 延迟的到来TRANSID_AI 与用户线程事务的关闭交织在一起，这样处理就可以在 重置事务状态并使接收者无效 TRANSID_AI 之前通过正常检查 。closeTransaction()

    当这些条件都满足时，接收器线程继续TRANSID_AI使用无效接收器处理信号。由于接收器已经失效，因此使用它会导致节点故障。

    现在Ndb完成的对象清理 TCROLLBACKREP包括事务 ID 的无效，因此，对于给定的事务，在TCROLLBACKREP 到达之后收到的任何信号都没有通过事务 ID 检查并被静默丢弃。此修复也适用于 TC_COMMITREF、 TCROLLBACKREF、 TCKEY_FAILCONF和 TCKEY_FAILREF信号。

    有关 NDB 消息传递的其他信息， 另请参阅 操作和信号。（漏洞 #18196562）

  • NDB Cluster API： 该示例 ndbapi-examples/ndbapi_blob_ndbrecord/main.cpp 包含一个内部头文件 (ndb_global.h)，在 MySQL NDB Cluster 二进制分发版中找不到。该示例现在使用 stdlib.h和string.h 代替此文件。（缺陷 #18096866，缺陷 #71409）

  • NDB Cluster API： 当Dictionary::dropTable() 尝试（作为其内部操作的正常部分）删除外键约束使用的索引时，删除失败。现在在这种情况下，调用dropTable()会导致删除表上的所有外键，无论此表充当父表、子表还是两者。

    此问题不影响使用 SQL 语句删除索引。（漏洞 #18069680）

    参考资料：另请参阅：错误 #17591531。

  • NDB Cluster API： ndb_restore有时会报告 在并行恢复时不必要地忙于其他模式操作。（漏洞#17916243）

  • 当一条ALTER TABLE语句更改了表架构而没有导致表分区发生变化时，新表定义不会从旧定义中复制散列映射，而是使用当前默认的散列映射。但是，表数据没有根据新的散列映射进行重组，如果两个散列映射具有不兼容的定义，这使得使用主键查找无法访问某些行。

    为了防止这种情况发生，任何ALTER TABLE需要更改哈希图的操作现在都会触发表的重组。此外，在这种情况下复制表定义时，哈希图现在也会被复制。（漏洞#18436558）

  • 当某些查询在节点故障之前生成的信号具有超过 18 个数据字时，此类信号未正确写入跟踪文件中。（漏洞 #18419554）

  • 超时检查由 signal 处理 TIME_SIGNAL。以前，此信号由QMGR NDB主线程中的内核块生成，并根据需要发送到QMRG、 DBLQH和DBTC块（请参阅NDB 内核块）以检查（分别）心跳、磁盘写入和事务超时。在ndbmtd（与 ndbd相反）中，这些块都在不同的线程中执行。这意味着，例如，如果 QMGR正在积极工作，而其他一些线程被置于休眠状态，则先前休眠的线程会收到大量TIME_SIGNAL当它再次被唤醒时同时发送消息，效果是有效时间在DBLQH 和DBTC中移动得非常快。在 DBLQH中，这没有明显的不利影响，但在DBTC中并非如此；后一个块无法处理事务，即使时间仍在推进，导致许多操作似乎超时的情况，因为事务协调器 (TC) 线程在响应请求时相对较慢。

    另外，当TC线程休眠时间超过1500毫秒时，由于检测到超时处理循环还没有停止，导致数据节点崩溃。为纠正此问题，TIME_SIGNAL 已将 的生成移至本地线程而不是 QMGR; 这样可以更好地控制TIME_SIGNAL允许消息到达的速度。（漏洞 #18417623）

  • ndb_mgmd 的 输出中不包含 ServerPort和 配置参数。（漏洞 #18366909）TcpBind_INADDR_ANY --print-full-config

  • 删除NDB表后，集群日志和REPORT MemoryUsage命令输出均未显示该 IndexMemory表使用的内存已被释放，即使内存实际上已被释放。MySQL NDB Cluster 7.3.2 中引入了此问题。（漏洞#18296810）

  • ndb_show_tables有时会失败并显示错误消息无法连接到管理服务器并立即终止，而没有提供失败的根本原因。Ndb_cluster_connection为了在这种情况下提供更有用的信息，该程序现在还打印用于实例化连接的对象的最新错误 （漏洞#18276327）

  • -DWITH_NDBMTD=0没有正确运行，这可能导致构建在 ARM 和 Raspberry Pi 等平台上失败，这些平台没有定义编译ndbmtd所需的内存屏障功能。（漏洞#18267919）

    参考资料：另请参阅：错误 #16620938。

  • 由多线程调度程序管理的块线程通过将信号放置在所有块线程之间设置的输出队列或作业缓冲区中进行通信。这个队列有一个固定的最大大小，所以当它被填满时，工作线程必须等待消费者清空队列。在一个高负载的系统中，多个线程可能会由于缓冲区已满而陷入循环等待锁定，这样它们就会阻止彼此执行任何有用的工作。这种情况最终导致数据节点被宣告死亡并被看门狗定时器杀死。

    为了解决这个问题，我们检测循环等待锁即将开始的情况，并导致保留的缓冲区可用于高负载队列的信号处理。（漏洞 #18229003）

  • 当在预期事件之前收到 ping 时， ndb_mgm客户端START BACKUP命令（请参阅 NDB Cluster Management Client 中的命令BackupCompleted）可能会遇到偶尔的随机故障。现在，在正确设置之前，不会检查通过此命令建立的连接。（漏洞 #18165088）

  • 当使用外键引用另一个表中的索引创建表时，有时即使索引中列的顺序不匹配，也可能会创建外键，因为并不总是在内部返回适当的错误. 此修复改进了在大多数情况下内部使用的错误；但是，如果父索引是唯一索引，仍然有可能出现这种情况。（缺陷号 18094360）

  • 更新外键的父表使用了过多的扫描资源，因此需要异常高的 MaxNoOfLocalScans和 设置MaxNoOfConcurrentScans。（漏洞 #18082045）

  • 在表上删除不存在的外键 NDB（例如，使用 ALTER TABLE）似乎成功了。现在，在这种情况下，语句会像预期的那样失败并显示相关错误消息。（漏洞#17232212）

  • 在执行包含大量表的 MySQL NDB Cluster 从 NDB 7.2.5 之前的版本到 7.2.5 或更高版本的在线升级时，运行ndbmtd的 数据节点可能会停止。（漏洞 #16693068）