Documentation Home
MySQL NDB Cluster 8.0 发行说明  / 发布系列变更日志:MySQL NDB Cluster 8.0  /  MySQL NDB Cluster 8.0.13 的变化(2018-10-23,发展里程碑)

MySQL NDB Cluster 8.0.13 的变化(2018-10-23,发展里程碑)

添加或更改的功能

  • 重要变更;NDB Disk Data: 对表中Disk Data文件的信息显示做了如下改动 INFORMATION_SCHEMA.FILES

    • 表空间和日志文件组不再显示在FILES表中。(这些构造实际上不是文件。)

    • 每个数据文件现在由表中的一行表示 FILES。每个撤消日志文件现在在该表中也仅由一行表示。(以前,每个数据节点上的每个文件的每个副本都显示一行。)

    • 对于数据文件或undo log文件对应的行,节点ID和undo log buffer信息不再显示在表的EXTRA列中 FILES

      重要的

      在 NDB 8.0.15 中恢复了撤消日志缓冲区信息的删除。(缺陷 #92796,缺陷 #28800252)

  • 重要变更;NDB 客户端程序:删除了perror 的弃用--ndb选项 。改为使用ndb_perror从 错误代码中获取错误消息信息(缺陷 #81705,缺陷 #23523957)NDB

    参考资料:另请参阅:Bug #81704、Bug #23523926。

  • 重要变化: 从这个版本开始,MySQL NDB Cluster 在新的统一发布模型下与标准 MySQL 8.0 服务器并行开发,具有以下特性:

    • NDB 8.0 是在 MySQL 8.0 源代码树中开发、构建和发布的。

    • NDB Cluster 8.0 版本的编号方案遵循 MySQL 8.0 的方案,从当前的 MySQL 版本(8.0.13)开始。

    • 使用 NDB 支持构建源附加 到mysql-cluster返回的版本字符串,如下所示: -V

      shell≫ mysql -V
      mysql  Ver 8.0.13-cluster for Linux on x86_64 (Source distribution)

      NDB 二进制文件继续显示 MySQL 服务器版本和 NDB 引擎版本,如下所示:

      shell> ndb_mgm -V
      MySQL distrib mysql-8.0.13 ndb-8.0.13-dmr, for Linux (x86_64)

      在 MySQL Cluster NDB 8.0 中,这两个版本号始终相同。

    要构建支持 NDB Cluster 的 MySQL 8.0.13(或更高版本)源,请使用 CMake 选项 -DWITH_NDBCLUSTER

  • NDB Cluster API: 添加了Table方法 getExtraMetadata()setExtraMetadata().

  • INFORMATION_SCHEMA表现在填充了 MySQL 集群表的表空间统计信息。(漏洞#27167728)

  • 现在可以指定一组核心用于 I/O 线程执行离线多线程构建有序索引,而不是正常的 I/O 任务,如文件 I/O、压缩或解压缩。离线在此上下文中是指在未写入父表时执行的有序索引的构建;这种构建发生在NDB集群执行节点或系统重启时,或者作为使用 ndb_restore --rebuild-indexes从备份恢复集群的一部分。

    此外,离线索引构建工作的默认行为被修改为使用 ndbmtd可用的所有内核,而不是将其自身限制为为 I/O 线程保留的内核。这样做可以改善重启和恢复时间以及性能、可用​​性和用户体验。

    此增强功能的实现方式如下:

    1. 默认值 BuildIndexThreads从 0 更改为 128。这意味着离线有序索引构建现在默认是多线程的。

    2. 的默认值 TwoPassInitialNodeRestartCopy 从更改falsetrue。这意味着初始节点重启首先将所有数据从 节点复制到正在启动的节点——不创建任何索引——离线构建有序索引,然后再次将其数据与活节点同步,即同步两次和在两个同步之间离线构建索引。这会导致初始节点重启的行为更像节点的正常重启,并减少构建索引所需的时间。

    3. idxbld为配置参数定义了 一个新的线程类型 ( ) ThreadConfig ,以允许将离线索引构建线程锁定到特定的 CPU。

    此外,现在通过以下两个标准 来区分ThreadConfigNDB可访问的线程类型:

    1. 该线程是否为执行线程。main, ldm, recv, rep, tc, 和类型 send的线程是执行线程;线程类型iowatchdogidxbld 不是。

    2. 给定任务的线程分配是永久的还是临时的。idxbld目前,除永久性之外的 所有线程类型 。

    有关其他信息,请参阅手册中的参数说明。(错误#25835748,错误#26928111)

  • 在执行 NDB 备份时,该 表现在ndbinfo.logbuffers显示有关每个数据节点上备份进程的缓冲区使用情况的信息。这被实现为反映除了 REDO和之外的两种新日志类型的行DD-UNDO。其中一行的日志类型为BACKUP-DATA,它显示备份期间用于将片段复制到备份文件的数据缓冲区量。另一行的日志类型为 BACKUP-LOG,它显示备份期间用于记录备份开始后所做更改的日志缓冲区的数量。这些 log_type行中的每一行都显示在 logbuffers集群中每个数据节点的表。具有这两种日志类型的行仅在当前正在进行 NDB 备份时才会出现在表中。(缺陷号 25822988)

  • 添加了 ODirectSyncFlag 数据节点的配置参数。启用后,数据节点会将所有已完成的文件系统写入重做日志,就好像它们是使用fsync.

    笔记

    如果至少满足以下条件之一,则此参数无效:

    • ODirect未启用。

    • InitFragmentLogFiles 设置为SPARSE

    (缺陷号 25428560)

  • 添加了ndbdndbmtd--logbuffer-size的选项,用于调试大量日志消息。这控制了数据节点日志缓冲区的大小;默认值 (32K) 用于正常操作。(漏洞 #89679,漏洞 #27550943)

  • 在 NDB 8.0 之前,所有字符串散列都是基于首先将字符串转换为规范化形式,然后对生成的二进制图像进行 MD5 散列。这可能会导致一些性能问题,原因如下:

    • 规范化的字符串总是用空格填充到它的全长。对于 a VARCHAR,这通常涉及添加比原始字符串中的字符更多的空格。

    • 字符串库未针对此空间填充进行优化,并且在某些用例中增加了相当大的开销。

    • 字符集之间的填充语义各不相同,其中一些字符集没有填充到它们的全长。

    • 即使没有空格填充,转换后的字符串也会变得非常大;一些 Unicode 9.0 归类可以将单个代码点转换为 100 个字节或更多的字符数据。

    • 随后的 MD5 散列主要由空格填充组成,效率不是特别高,可能会因刷新 L1 缓存的重要部分而导致额外的性能损失。

    排序规则提供了自己的哈希函数,可以直接对字符串进行哈希处理,而无需先创建规范化字符串。此外,对于 Unicode 9.0 归类,哈希值的计算没有填充。NDB现在,每当对标识为使用 Unicode 9.0 排序规则的字符串进行哈希处理时,都会利用此内置函数。

    因为,对于其他排序规则,存在在转换后的字符串上进行散列分区的现有数据库,因此 NDB继续采用以前的方法对使用这些的字符串进行散列,以保持兼容性。(漏洞 #89609,漏洞 #27523758)

    参考资料:另请参阅:Bug #89590、Bug #27515000、Bug #89604、Bug #27522732。

  • 在 NDB 7.6 及更早版本中创建的表包含压缩.frm文件形式的元数据,MySQL 8.0 不再支持该格式。为了方便在线升级到 NDB 8.0,NDB执行此元数据的即时转换并将其写入 MySQL 服务器的数据字典,这使得 NDB Cluster 8.0 中的mysqld可以使用该表,而不会阻止后续使用该表以前版本的 NDB软件。

    重要的

    一旦在 NDB 8.0 中修改了表的结构,其元数据将使用数据字典存储,NDB 7.6 及更早版本将无法再访问它。

    此增强功能还可以将 NDB使用早期版本制作的备份还原到运行 NDB 8.0(或更高版本)的集群。

修正错误

  • 重要变更;NDB 磁盘数据: 可以发出CREATE TABLE引用不存在的表空间的语句。现在这样的声明失败并出现错误。(缺陷 #85859,缺陷 #25860404)

  • 重要更改: 语句选项 NDB支持以下三个值中的任何一个、和 。以前,除了这些之外的任何值都被接受但导致 被使用。现在,尝试创建表的语句失败并出现错误(如果使用),并且没有列出的三个值之一。(漏洞 #88803,漏洞 #27230898)CREATE TABLEROW_FORMATDEFAULTFIXEDDYNAMICDYNAMICCREATE TABLENDBROW_FORMAT

  • 微软Windows; ndbinfo 信息数据库:RESTART在 Windows 平台上用于生成和重新启动 mysqld 的监视进程的进程 ID现在在 ndbinfo.processes表中显示为 angel_pid. (缺陷 #90235,缺陷 #27767237)

  • NDB Cluster APIs: 示例 NDB API 程序 ndbapi_array_simple并且 ndbapi_array_using_adapter在执行后没有执行清理;另外,示例程序 ndbapi_simple_dual没有检查本示例使用的表是否已经存在。由于这些问题,这些示例中没有一个可以连续运行多次。

    刚刚描述的问题已在示例源中得到纠正,并且 NDB API 文档中的相关代码清单已更新以匹配。(错误号 27009386)

  • NDB Cluster APIs: 之前修复的一个问题,在部分重启期间多个数据节点的故障可能导致 API 节点失败,在继续之前没有正确检查关联 NdbReceiver对象的有效性。现在在这种情况下,无效对象会触发对无效信号的处理,而不是节点故障。(漏洞 #25902137)

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

  • NDB Cluster API:setBound() 在用于指定NULL边界 时返回不正确的结果,通常是空结果集 这个问题似乎是由 gcc 中的问题引起的,仅限于使用此方法的旧版本(不使用NdbRecord)的情况,并且通过在旧实现中重写有问题的内部逻辑来解决。(漏洞 #89468,漏洞 #27461752)

  • NDB Cluster APIs: 发布的 NDB API 对象保存在一个或多个 Ndb_free_list结构中以供以后重用。每个列表还跟踪从它那里夺取的所有对象,并确保这些对象最终被释放回给它。如果内部函数 NdbScanOperation::init()失败,则可能会泄漏NdbApiSignal已分配的NdbOperation现在在这种情况下, NdbScanOperation::release()调用以释放由失败分配的任何对象, NdbScanOperation然后再将其返回到空闲列表。

    此修复程序还处理了与 类似的问题 NdbOperation::init(),其中失败的调用也可能会泄漏信号。(漏洞 #89249,漏洞 #27389894)

  • NDB Cluster APIs: 删除了未使用的TFSentinel实现类,它在 32 位系统上引发了编译器警告。(缺陷 #89005,缺陷 #27302881)

  • NDB Cluster APIs: 并不总是检查通过 API 调用创建线程是否成功,这在某些情况下可能导致超时。(漏洞 #88784,漏洞 #27225714)

  • NDB Cluster API: 文件storage/ndb/src/ndbapi/ndberror.c 已重命名为ndberror.cpp. (漏洞 #87725,漏洞 #26781567)

  • NDB 客户端程序: 当传递无效的连接字符串时, ndb_mgm客户端并不总是在退出前释放所有使用的内存。(漏洞 #90179,漏洞 #27737906)

  • NDB 客户端程序: ndb_show_tables并不总是释放它使用的所有内存。(缺陷 #90152,缺陷 #27727544)

  • 本地检查点并不总是 DROP TABLE正确处理操作。(漏洞 #27926532)

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

  • 在某些情况下,当 DBTC块中的事务中止时,仍然存在指向尚未引用计数的操作记录的触发记录的链接,但是当这样的操作记录被释放时,触发引用计数仍然递减。(缺陷号 27629680)

  • 内部缓冲区在释放后立即被重用可能会导致数据节点意外关闭。(漏洞#27622643)

    参考资料:另请参阅:Bug #28698831。

  • 联机备份由NDB模糊数据以及重做和撤消日志组成。要恢复到一致的状态,有必要确保日志包含跨越模糊数据部分捕获和一致快照点的所有更改。这是通过在数据捕获完成后等待通过 GCI 边界来实现的,但在停止更改日志记录和在备份元数据中记录停止 GCI 之前。

    在恢复时,日志会重播到停止 GCI,将系统恢复到一致停止 GCI 时的状态。当在负载下,可能会选择出现得太早且未跨越所有捕获数据的 GCI 边界时,就会出现问题。这可能会导致恢复备份时出现不一致;这些可能会被视为破坏约束或损坏的BLOB条目。

    现在选择停止 GCI,以便它跨越模糊数据捕获过程的整个持续时间,以便备份日志始终包含给定停止 GCI 内的所有数据。(漏洞#27497461)

    参考资料:另请参阅:Bug #27566346。

  • 对于NDB表,当外键作为 DDL 语句的一部分添加或删除时,所有引用的父表的外键元数据应重新加载到连接到集群的所有 SQL 节点上的处理程序中,但这仅在执行语句的mysqld 。因此,任何依赖于来自相应父表的外键元数据的后续查询都可能返回不一致的结果。(漏洞#27439587)

    参考资料:另请参阅:Bug #82989、Bug #24666177。

  • ANALYZE TABLE在大型低基数表上使用过多的 CPU。(漏洞#27438963)

  • 使用非常大的列表的查询IN没有得到正确处理,这可能导致数据节点故障。(缺陷号 27397802)

    参考资料:另请参阅:Bug #28728603。

  • 数据节点过载在某些情况下可能会导致数据节点意外关闭,从而导致所有数据节点与管理和节点断开连接。

    这是由于 API_FAILREQ在节点故障之前不是最后接收到的信号的情况。

    作为此修复的一部分,事务协调 SCAN_TABREQ器对处于不正确状态的信号 的处理ApiConnectRecord也得到了改进。(漏洞 #27381901)

    参考资料:另请参阅:Bug #47039、Bug #11755287。

  • 在双节点集群中,当 ID 最低的节点开始使用--nostart时,API 客户端无法连接,失败并显示Could not alloc node id at HOST port PORT_NO: No free node id found for mysqld(API)。(漏洞 #27225212)

  • MaxNoOfExecutionThreads 在没有初始系统重启的情况下进行 更改 会导致数据节点意外关闭。(缺陷号 27169282)

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

  • 在大多数情况下,尤其是在错误情况下, NDB命令行程序在退出时无法释放选项处理所使用的内存,并且无法调用 ndb_end(). 这是通过删除内部方法ndb_load_defaults()ndb_free_defaults()from 来 解决的storage/ndb/include/util/ndb_opts.h,并将它们替换为一个Ndb_opts自动释放此类资源的类作为其析构函数的一部分。(缺陷号 26930148)

    参考资料:另请参阅:Bug #87396、Bug #26617328。

  • INFORMATION_SCHEMA.FILES当表包含一个ORDER BY子句时,对该表 的查询 未返回任何结果。(漏洞#26877788)

  • 在重新启动期间DBLQH,从一个或多个重做日志文件加载它管理的每个重做日志部分的重做日志部分元数据。由于每个文件的元数据容量有限,因此必须查阅的文件数量取决于重做日志部分的大小。这些文件按顺序打开、读取和关闭,但一个文件的关闭与下一个文件的打开同时发生。

    在文件关闭速度很慢的情况下,每个重做日志部分可能同时打开超过 4 个文件;由于这些文件是使用该 OM_WRITE_BUFFER选项打开的,因此在这种情况下,每个部分分配了 4 个以上的写入缓冲区块。写缓冲池不是无限的;如果所有重做日志部分都处于相似状态,则池已耗尽,导致数据节点关闭。

    这个问题通过避免 OM_WRITE_BUFFER在元数据重新加载期间使用来解决,这样每​​个日志文件部分超过 4 个重做日志文件的任何瞬时打开都不会再导致数据节点失败。(错误号 25965370)

  • 在某些情况下,数据节点在执行期间不必要地重新启动 ALTER TABLE... REORGANIZE PARTITION。(漏洞#25675481)

    参考资料:另请参阅:Bug #26735618、Bug #27191468。

  • 竞争条件有时会在传输器异步断开连接和重新连接期间发生,而其他线程同时将信号数据插入发送缓冲区,导致集群意外关闭。

    作为解决此问题的工作的一部分,Transporter Registry 在准备发送时使用的内部模板函数被重构为使用可能或不太可能的逻辑来加快执行速度,并删除了一些对 NULL 的重复检查。(错误#24444908,错误#25128512)

    参考资料:另请参阅:Bug #20112700。

  • ndb_restore有时记录的数据文件和日志文件进度值远大于 100%。(缺陷号 20989106)

  • 从内部函数中删除了不需要的调试打印输出 ha_ndbcluster::copy_fk_for_offline_alter()。(缺陷 #90991,缺陷 #28069711)

  • 内部函数BitmaskImpl::setRange() 设置比指定的少一位。(缺陷 #90648,缺陷 #27931995)

  • 将一行插入到NDB具有自引用外键的表中,该外键引用了表上的唯一索引而不是主键,失败并返回 ER_NO_REFERENCED_ROW_2。这是因为在NDB更新唯一索引之前检查了外键约束,导致约束检查无法使用索引来定位行。现在,在这种情况下,NDB等到所有唯一索引值都已更新,然后再检查插入行的外键约束。(缺陷 #90644,缺陷 #27930382)

    参考资料:另请参阅:Bug #91965、Bug #28486390。

  • 删除register 了 NDB Cluster 源中对 C++ 存储类的所有引用;使用此说明符(在 C++11 中已弃用并在 C++17 中删除)在使用最新编译器构建时会引发警告。(缺陷 #90110,缺陷 #27705985)

  • 无法 使用set to 、 或 来创建NDB表 。(缺陷 #89811,缺陷 #27602352)PARTITION_BALANCEFOR_RA_BY_LDM_X_2FOR_RA_BY_LDM_X_3FOR_RA_BY_LDM_X_4

    参考:此问题是 Bug #81759、Bug #23544301 的回归。

  • 为具有多个数据节点的集群向全局配置文件添加一个[tcp][shm] 部分导致默认 TCP 连接丢失到使用单个部分的节点。(漏洞 #89627,漏洞 #27532407)

  • 删除了配置文件解析器中的内存泄漏。(漏洞 #89392,漏洞 #27440614)

  • 修复了一些隐式失败警告、未初始化值引发的警告以及NDB使用 GCC 7.2.0 编译时遇到的其他警告。(错误#89254、错误#89255、错误#89258、错误#89259、错误#89270、错误#27390714、错误#27390745、错误#27390684、错误#27390816、错误#27396662)

    参考资料:另请参阅:Bug #88136、Bug #26990244。

  • 节点连接状态并不总是 ClusterMgr在报告断开连接后立即正确报告。(缺陷 #89121,缺陷 #27349285)

  • 由于在执行辅助发送时重用了用于发送线程的代码,所有本地释放发送缓冲区都被释放到全局池中,这导致本地发送缓冲池的预期级别被忽略。现在发送线程和辅助工作线程遵循它们自己的策略来维护它们的本地缓冲池。(错误#89119,错误#27349118)

  • PGMAN块使用 获取新 Page_request记录 seizeLast时,未检查其返回值,这可能导致访问无效内存。(缺陷 #89009,缺陷 #27303191)

  • TCROLLBACKREPDBTC内核块未正确处理信号。(漏洞 #89004,漏洞 #27302734)

  • 当发送优先级 A 信号时,我们现在确保显式初始化未决信号的数量。(错误#88986,错误#27294856)

  • 内部函数 ha_ndbcluster::unpack_record()没有执行正确的错误处理。(漏洞 #88587,漏洞 #27150980)

  • CHECKSUM表不支持 NDB,但这并没有反映在表的CHECKSUM列中 INFORMATION_SCHEMA.TABLES,在这种情况下可能会假定一个随机值。现在此列的值始终设置 NULLNDB表,就像表一样InnoDB。(漏洞 #88552,漏洞 #27143813)

  • 删除了运行ndb_mgm -e "CLUSTERLOG ..."时检测到的内存泄漏。(错误#88517,错误#27128846)

  • 终止时,ndb_config没有释放它使用的所有内存。(漏洞 #88515,漏洞 #27128398)

  • ndb_restore在退出前没有正确释放内存。(漏洞 #88514,漏洞 #27128361)

  • 在某些情况下,从 API 节点并行使用多个对象时,即使请求来自Ndb API 节点,从块引用中提取的块编号与块的编号 DBLQH相同 。SUMA由于这种歧义, DBLQH将来自 API 节点的请求误认为是来自SUMA区块的请求而失败。这是通过在检查块号之前检查节点 ID 来解决的。(缺陷 #88441,缺陷 #27130570)

  • 完全在半连接的具体化部分内的连接不会被推送,即使它本来可以被推送。此外, EXPLAIN没有提供有关为什么未推送连接的信息。(错误#88224,错误#27022925)

    参考资料:另请参阅:Bug #27067538。

  • -Werror 构建源代码时 引发的所有已知编译器警告NDB均已修复。(漏洞 #88136,漏洞 #26990244)

  • 当重复剔除算法用于评估半连接时,结果有缺失的行。(错误#88117,错误#26984919)

    参考资料:另请参阅:Bug #87992、Bug #26926666。

  • NDB没有用 GCC 7 编译。(错误 #88011,错误 #26933472)

  • 松散扫描中使用的表可以用作推送连接查询中的子项,从而可能导致不正确的结果。(错误#87992,错误#26926666)

  • 当在查询计划中表示物化半连接时,MySQL 优化器插入额外的QEP_TABJOIN_TAB对象来表示对物化子查询结果的访问。连接下推分析器没有为这些正确设置其内部数据结构,而是让它们未初始化。这意味着以后使用任何引用物化半连接的项目对象tableno在访问 64 位位tableno掩码时会访问已初始化的列,可能引用超出其末尾的点,从而导致 SQL 节点意外关闭。(漏洞 #87971,漏洞 #26919289)

  • 在某些情况下,在发送带有关闭标志的SCAN_FRAGCONF信号后会收到信号,从而清除计时器。SCAN_FRAGREQ发生这种情况时,下一个SCAN_FRAGREF到达会导致时间跟踪失败。SCAN_FRAGREF现在在这种情况下,会在处理消息之前检查已清除的计时器 。(错误#87942,错误#26908347)

  • 在删除 中的元素Dbacc或在哈希表扩展或缩减期间移动它时,使用的方法 ( getLastAndRemove()) 可以返回对已释放页面上已删除元素的引用,稍后可以从调用它的函数中引用该元素。这是由于 NDB 7.6.2 中动态索引内存的实现带来的变化;以前,该页面始终属于单个Dbacc实例,因此访问它是安全的。更改后不再是这种情况;释放的页面Dbacc可以直接放入全局页面池中,然后任何其他线程都可以分配它。

    现在我们确保新释放的页面 Dbacc保留在当前 Dbacc实例中,而不是直接交给全局页面池。此外,已删除对已发布页面的引用;受影响的内部方法现在按值而不是按引用返回最后一个元素。(漏洞 #87932,漏洞 #26906640)

    参考资料:另请参阅:Bug #87987、Bug #26925595。

  • 创建不存在冲突检测函数的表时,NDB返回不正确的错误信息。(漏洞 #87628,漏洞 #26730019)

  • ndb_top构建失败,错误 为“HAVE_NCURSESW_H”未定义。(缺陷 #87035,缺陷 #26429281)

  • 在一个配置有一个 MySQL 服务器的 MySQL 集群中,当创建和使用 NDB具有非存储生成列的表时发生二进制日志失败。只有当产品是在调试支持下构建时才会出现问题。(漏洞 #86084,漏洞 #25957586)

  • STORAGE MEMORY可以使用不存在 的表空间创建或更改表而不会产生任何错误。这样的操作现在会 ER_TABLESPACE_MISSING_WITH_NAME按预期失败并出现 Error 3510 。(错误#82116,错误#23744378)

  • ndb_restore 没有打印 值的尾随 0。(漏洞 #65560,漏洞 #14198580)--print-data --hexLONGVARBINARY

  • 当内部函数 ha_ndbcluster::copy_fk_for_offline_alter() 检查应该从中删除外键的表上的依赖对象时,它没有对外键执行任何过滤,这使得它有可能尝试检索索引或触发器,从而导致虚假错误 723(没有这样的表)。