Documentation Home
MySQL NDB Cluster 7.5 发行说明  / 发布系列变更日志:MySQL NDB Cluster 7.5  /  MySQL NDB Cluster 7.5.1(5.7.11-ndb-7.5.1)的变化(2016-03-18,发展里程碑)

MySQL NDB Cluster 7.5.1(5.7.11-ndb-7.5.1)的变化(2016-03-18,发展里程碑)

添加或更改的功能

  • 重要更改: 在创建列或向NDB 表中添加列时,用于 COLUMN_FORMATROW_FORMAT选项的默认值现在是 DYNAMIC而不是FIXED

    此更改不会影响现有表使用的行格式或列格式。添加到此类表的新列使用新的默认值,并且现有列也更改为使用这些默认值,前提是相关ALTER TABLE 语句使用ALGORITHM=COPY. 请注意,如果运行 mysqld--ndb-allow-copying-alter-table=FALSE (默认为TRUE) ,则不能隐式完成此操作 。

    添加了一个新的 MySQL 服务器选项 --ndb-default-column-format以实现向后兼容性;将其设置为 FIXED以强制将旧的默认值用于COLUMN_FORMATROW_FORMAT

    笔记

    此行为更改在 MySQL NDB Cluster 7.5.4 中被取代。

  • 通过用支持直接执行并允许消除 and 以及 for 和 信号 的 signal 替换 DIH_SCAN_GET_NODES_REQ以前用于DBTCDBDIH内核块 之间通信NDB的 signal 来改进扫描。在某些情况下,通过将用于扫描操作的 CPU 资源使用减少约 5%,这可以在用于扫描操作时实现更高的数据节点可扩展性。这也应该会缩短响应时间,这有助于防止主线程过载的问题。 DIGETNODESREQDIH_SCAN_GET_NODES_REFDIH_SCAN_GET_NODES_CONFDIH_SCAN_TAB_REQDIH_SCAN_TAB_COMPLETE_REPEXECUTE_DIRECT

    作为这些更改的一部分,在 BACKUP内核块中进行的扫描也得到了改进并变得更加高效。

    参考资料:另请参阅:Bug #80640、Bug #22884995。

  • 对集群日志中的事件缓冲区报告进行了以下改进:

    • 每个报告现在都标识发送它的 API 节点。

    • 报告中显示的字段已得到改进和扩展。现在可以更好地指定百分比,并仅在适当的时候使用。为了提高清晰度, apply_epochlatest_epoch字段已分别重命名为 latest_consumed_epochlatest_buffered_epoch。现在显示用作报告源的对象的 ID,Ndb以及生成报告的原因(作为 report_reason字段)。

    • 通过将报告限制为仅显示事件缓冲区使用情况的重大变化的报告,减少了不必要报告的频率。

    • MGM API 添加了一个新的 NDB_LE_EventBufferStatus2事件类型来处理新事件缓冲区报告提供的附加信息。旧版本的 MySQL NDB Cluster 中使用的 NDB_LE_EventBufferStatus事件类型现已弃用,最终将被删除。

    有关详细信息,请参阅 集群日志中的事件缓冲区报告以及 ndb_logevent 结构

修正错误

  • 重要更改:数据节点配置参数 的最小值 BackupDataBufferSize 已从 2 MB 降低到 512 KB。此参数的默认值和最大值保持不变。(漏洞 #22749509)

  • OS X: 由于变量未初始化,本地检查点的处理在 Mac OS X 上未正确处理。(缺陷 #80236,缺陷 #22647462)

  • Microsoft Windows:ConfigInfo.cpp由于 Visual Studio 对空格和串联的处理发生了变化,在 中使用 Visual Studio 2015 编译 MySQL 失败 (漏洞 #22558836,漏洞 #80024)

  • Microsoft Windows:在 Windows 上为ndb_mgmd 设置事件日志记录时,MySQL NDB Cluster 会尝试将注册表项添加到 HKEY_LOCAL_MACHINE,如果用户无权访问注册表,则会失败。在这种情况下, ndb_mgmd记录了错误Could neither create or open key,这是不准确的,并且可能会给可能没有意识到文件日志记录可用和正在使用的用户造成混淆。现在在这种情况下, ndb_mgmd会记录警告无法创建或访问应用程序记录到 Windows 事件日志所需的注册表项。以足够的权限运行应用程序一次以创建密钥,或手动添加密钥,或关闭该应用程序的日志记录。现在仅当ndb_mgmd事件日志记录根本没有可用输出时,才会在这种情况下报告错误(而不是警告) 。(缺陷号 20960839)

  • Microsoft Windows: MySQL NDB Cluster 无法使用 Microsoft Visual Studio 2015 正确编译,因为该_vsnprintf() 函数的 VS 实现与以前版本相比发生了变化。(缺陷 #80276,缺陷 #22670525)

  • 在节点故障处理期间,用于驱动清理操作的请求结构在执行请求时未正确维护。这会导致在正常操作期间无害的不一致,但这些可能会导致节点故障处理期间的断言失败,并导致其他节点随后发生故障。(漏洞 #22643129)

  • 在某些情况下,发现先前针对内部 TransporterFacade::deliver_signal()函数缺少互斥锁保护的修复不完整。(漏洞 #22615274)

    参考资料:此问题是 Bug #77225、Bug #21185585 的回归。

  • 当在一个 SQL 节点上将二进制日志设置为原子操作失败时,这可能会在其他 SQL 节点中触发一种状态,在这种状态下,它们似乎检测到参与模式更改分发的 SQL 节点,而它尚未完成二进制日志设置。当 SQL 节点仍在重试二进制日志设置时需要此锁,而另一个 mysqld 已将锁作为模式更改操作的一部分,这又可能导致全局元数据锁出现死锁。在这种情况下,第二个 SQL 节点等待第一个 SQL 节点对其模式分布更改采取行动,但它还不能这样做。(缺陷号 22494024)

  • 当在包含唯一索引的备份上运行ndb_restore 时,可能会发生重复键错误 。这是因为在恢复数据期间,数据库在完成之前可能会经历一个或多个不一致状态,这样的不一致状态可能对具有唯一索引的列具有重复值。(如果数据恢复之前是运行 with --disable-indexes,然后 是运行 with --rebuild-indexes,则可以避免这些错误。)

    添加了对备份中唯一索引的检查,该检查仅在恢复数据时执行,并且不会处理已明确排除的表。对于找到的每个唯一索引,现在都会打印一条警告。(缺陷号 22329365)

  • NdbDictionary元数据操作有一个硬编码的 7 天超时,事实证明这对于短期操作(例如检索表定义)来说过长了。这可能会导致用户应用程序不必要地挂起,而这些挂起很难正确检测和处理。为帮助解决此问题,修改了超时行为,以便只读或短期字典交互具有 2 分钟的超时,而可能持续时间较长的架构事务保留现有的 7 天超时。

    这样的超时旨在作为一个安全网:如果出现问题,这些超时会将控制权返回给用户,然后用户可以采取纠正措施。任何可重现的 NdbDictionary超时问题都应报告为错误。(缺陷号 20368354)

  • 通过缓冲和定期发送信号来优化信号发送,或者当缓冲区变满时,可能会导致 SUB_GCP_COMPLETE_ACK信号过度延迟。为每个节点和纪元发送此类信号,最小间隔为 TimeBetweenEpochs;如果没有及时收到,SUMA 缓冲区可能会溢出。溢出导致 API 节点断开连接,导致当前事务因节点故障而中止。这种情况使得长事务(例如更改非常大的表)难以完成。现在在这种情况下,ACK 信号会被发送而不会被延迟。(漏洞 #18753341)

  • 设置 CPU 自旋时间时,该值在内部被不必要地转换为布尔值,因此将其设置为任何非零值都会产生有效值 1。此问题及其修复适用于设置 SchedulerSpinTimer 参数和设置spintimeThreadConfig 参数值的一部分。(缺陷 #80237,缺陷 #22647476)

  • if语句中 的逻辑错误使用于确定比较操作时是否应返回storage/ndb/src/kernel/blocks/dbacc/DbaccMain.cpp 的检查变得无用 。这是在使用 ZREAD_ERROR编译时检测到的 。(缺陷 #80155,缺陷 #22601798)gcc-Werror=logical-op

    参考资料:此问题是 Bug #21285604 的回归。

  • 抑制了因使用错误引用的变量名而导致的CMake警告。(缺陷 #80066,缺陷 #22572632)

  • 当使用在共享循环外键CREATE INDEX的两个NDB表中的任何一个上添加索引时,查询成功但磁盘上留下了一个临时表,打破了外键约束。当尝试在外键链中间的表上创建索引时,也会观察到此问题,即同时具有父键和子键但在不同表上的表。ALTER TABLE使用执行相同的索引创建操作时没有出现该问题 ;随后的分析揭示了 . 执行此类操作的方式存在意想不到的差异CREATE INDEX

    为了解决这个问题,我们现在确保CREATE INDEX语句执行的操作始终在内部以相同的方式处理,并且与 or 执行的操作ALTER TABLE相同DROP INDEX。(错误#79156,错误#22173891)

  • 在 MySQL 5.1.3 中弃用的PortNumberSCI、SHM 和 TCP 配置参数现在已被删除,配置文件中不再接受这些参数。

    此更改不会影响 PortNumber管理节点配置参数,其行为保持不变。(错误#77405,错误#21280456)