模式操作超时检测已从模式分发客户端转移到模式分发协调器，它现在定期检查正在进行的模式操作是否超时，标记已超时的参与者，在模式操作超时发生时发出适当的警告，并打印定期列出任何正在进行的模式操作。

作为这项工作的一部分，一个新选项 --ndb-schema-dist-timeout可以设置给定 SQL 节点等待模式操作被标记为超时的秒数。（漏洞#29556148）

添加了状态变量 Ndb_trans_hint_count_session，它显示了在当前会话中使用提示启动的事务数。将此与 进行比较， 可以得到当前会话中所有交易中已经能够使用提示Ndb_api_trans_start_count_session 的比例。NDB（缺陷号 29127040）

当集群处于单用户模式时， ndb_mgm SHOW命令的输出现在指示在该模式生效时哪个 API 或 SQL 节点具有独占访问权限。（漏洞 #16275500）

重要更改： 尝试使用mysql客户端NDB存在于 MySQL 数据字典中但不存在的表NDB导致 mysqld失败并出现错误。当使用ndb_drop_table工具或在 NDB API 应用程序中使用 NDB删除表时，可能会发生这种情况。现在在这种情况下， mysqld会从 MySQL 数据字典中删除表而不会引发错误。（漏洞#29125206）dropTable()

重要更改：ndb_restore对 NDBT仅用于内部测试的库 的依赖性NDBT_ProgramExit: ...这意味着程序在终止时不再打印依赖此行为的应用程序应在升级到此版本时进行更新以反映此更改。

打包： 将调试符号包添加到NDB 发行版中，.deb这些平台不会自动生成这些包。（缺陷号 29040024）

NDB 磁盘数据： 如果由于某种原因，磁盘数据表存在于 NDB 数据字典中，但不存在于 MySQL 服务器中，则通过安装对象来同步数据字典。这可能发生在 MySQL 服务器连接到 NDB Cluster 时的模式同步阶段，也可能发生在通过 DML 查询或 DDL 语句发现表期间。

对于使用表空间存储的磁盘数据表，表空间ID作为数据字典对象的一部分存储，但在同步时没有设置。（漏洞#29597249）

NDB 磁盘数据： 在同一 SQL 节点上执行的并发磁盘数据表和表空间 DDL 语句导致元数据锁定死锁。DDL 语句要求在被修改的对象上采用独占锁，而每个这样的锁又要求在NDB.

为解决此问题，NDB现在跟踪与表空间上的独占锁相对应的全局模式锁何时被占用。如果在第一次锁定时不同的全局模式锁定请求失败，则 NDB 假定存在死锁。在这种情况下，死锁的处理方式是让新请求释放它之前获得的所有锁，然后稍后重试。（漏洞#29394407）

参考资料：另请参阅：Bug #29175268。

NDB 磁盘数据： 执行后ALTER TABLESPACE，使用受影响表空间的现有表上的 SQL 语句失败，出现错误 3508 字典对象 ID ( id) 不存在，其中显示的对象 ID 指的是表空间。的模式分布ALTER TABLESPACE涉及从参与 SQL 节点上的数据字典中删除旧对象并创建具有不同字典对象 ID 的新对象，但 SQL 节点数据字典中的表对象仍然使用旧表空间 ID，这导致它在参与者们。

为了纠正这个问题，现在在创建新表空间之前检索并存储使用表空间的表，然后在数据字典中创建表空间后更新新的对象 ID。（漏洞#29389168）

NDB 复制： 该ndb_apply_status表是使用已弃用的语法创建的VARCHAR(255) BINARY。VARBINARY(255) 现在用于创建此表。（漏洞#29807585）

NDB 复制：未正确检查语句 从复制设置引发的错误 CREATE TABLE，导致用户（错误地）认为该表对于此目的有效。（缺陷号 29697052）

NDB 复制： NDB没有正确处理虚拟生成列类型的二进制日志记录BLOB 。现在，此类列始终被视为具有零长度。

NDB Cluster API： NDB 发行版中包含的 memcached 源不会使用-Werror=format-security. 现在，在编译这些文件时，警告不再被视为错误。（漏洞#29512411）

NDB Cluster API： 无法扫描 SingleUserMode属性设置为SingleUserModeReadWrite或 SingleUserModeReadOnly。（漏洞#29493714）

NDB Cluster API： MGM API ndb_logevent_get_next2() 函数在 Windows 和 32 位 Linux 平台上运行不正确。（缺陷 #94917，缺陷 #29609070）

ndb_setup.py 期望的 Python 版本 在某些平台上没有明确指定。（漏洞 #29818645）

缺少 SharedGlobalMemory被错误地报告为缺少撤消缓冲区内存，即使集群不使用磁盘数据表。（漏洞 #29806771）

参考资料：此问题是 Bug #92125、Bug #28537319 的回归。

从处理调用时， 长TCKEYREQ信号并不总是使用预期的格式。TCINDXREQ（漏洞#29772731）

内部可能 NDB_SCHEMA_OBJECT过早发布或根本不发布；此外，可以创建这样一个重用现有密钥的对象。（缺陷号 29759063）

ndb_restore有时使用 exit()而不是 exitHandler()终止程序，这可能导致资源未被正确释放。（漏洞#29744353）

改进了 FIXED超过列的最大偏移量时打印的错误消息。（漏洞 #29714670）

模式分发客户端和模式分发协调器之间的通信是使用 NDB_SCHEMA_OBJECT以及通过将行ndb_schema写入 NDB. 这允许在注册模式操作和通知协调器之间存在许多不同的竞争条件。

此修复解决了与刚才描述的情况相关的以下问题：

此外，删除了全局指针的使用，取而代之的是通过检查是否已创建ndb_schema_share 操作来检测模式分发是否准备就绪。（缺陷号 29639381）mysql.ndb_schemaNDB_SHARE

DataMemory设置为 200 GB 时，ndbmtd 无法启动。（错误号 29630367）

ABORT_BACKUP_ORD 当在等待缓冲区空间期间 由于接收到备份而失败时，备份调用closeScan()然后向块发送 SCAN_FRAGREQ信号 DBLQH以关闭扫描。作为接收SCAN_FRAGCONF响应的一部分， scanConf()调用文件记录的操作对象，后者又调用 updateWritePtr()文件系统缓冲区 ( FsBuffer)。此时发送的长度 updateWritePtr()应该为 0，但在这种情况下不是，这意味着缓冲区没有足够的空间，即使它没有，问题是大小计算为scanStop - scanStart并且这些值被保留因为以前的 SCAN_FRAGCONF已收到，但由于缓冲区空间不足而未重置。

为了避免这个问题，我们现在设置scanStart = scanStopin confirmBufferData() （以前scanConfExtra()称为）作为处理的一部分调用SCAN_FRAGCONF，间接地scanConf()用于备份和第一个本地检查点文件，并直接用于仅使用数据缓冲区操作记录的 LCP 文件。（漏洞 #29601253）

的设置 MaxDMLOperationsPerTransaction 未及时验证，如果其值超过 的值，则导致数据节点故障而不是管理服务器错误 MaxNoOfConcurrentOperations。（漏洞 #29549572）

DBTC在资源受限环境中的某些情况下， 数据节点可能会由于块中的断言而失败 。（漏洞#29528188）

如果重做日志已填充到容量的 25% 以上，则无法成功完成从早期版本升级到 NDB 7.6.9 或更高版本。（缺陷号 29506844）

当该DBSPJ块调用内部函数lookup_resume()来安排先前排队的操作时，它使用了一个相关 ID，该 ID 可能是从其执行顺序中的直接祖先生成的，而不是假设的查询树中的父级生成的。这可能在执行SELECT STRAIGHT_JOIN查询期间发生。

现在NDB检查执行祖先是否与查询树父项不同，如果不同，则执行查询树父项的查找，并将父项的相关 ID 排入队列以供稍后执行。（漏洞 #29501263）

当一个新的 master 接管，发送 MASTER_LCP_REQ信号并 MASTER_LCPCONF从参与节点执行时，它期望它们没有在前一个 master 下完成当前本地检查点，这不一定是真的。（错误#29487340，错误#29601546）

恢复TINYBLOB列时， ndb_restore现在将它们视为具有 BINARY字符集。（漏洞#29486538）

当从包含 LIMIT单个表子句的查询中选择排序结果集时，排序执行方式Using filesort和 ref访问方法用于有序索引时，结果集可能会丢失一行或多行. （漏洞#29474188）

由于临时重做错误， ndb_restore 恢复纪元失败。现在，当发生此类错误时， ndb_restore 会 重试纪元更新。（漏洞#29466089）

ndb_restore在检查以确定表是否为 blob 表时尝试提取表名的 8 个字符的子字符串，无论名称的长度如何。（漏洞#29465794）

当推送连接与访问方法结合使用时， 由于 NDB 8.0.16 中实现的 1 行缓存机制，作为该版本中完成的工作的一部分，通过允许引用eq_ref扩展条件下推，可能会获得不正确的连接结果NDB以前表格中的值。当表上定义了推送条件时，现在通过关闭此缓存机制并直接从处理程序读取行来解决此问题。（缺陷号 29460314）

改进并提高 ha_ndbcluster处理程序将行从内部使用的格式转换NDB为 MySQL 服务器用于既不包含 值BLOB也不 包含BIT值的列的格式，这是最常见的情况。（漏洞 #29435461）

DROP TABLE如果出现临时错误，可以尝试无限次 失败。现在在这种情况下，重试次数限制为 100 次。（缺陷 #29355155）

ndb_restore --restore-epoch错误地将停止 GCP 报告为比实际位置小 1。（漏洞 #29343655）

内核块中的SavedEvent对象 CMVMI被写入循环缓冲区。这样的对象在缓冲区末尾包装时被分成两部分；NDB查看缓冲区末尾以外的内容，而不是缓冲区开头的包装数据。（缺陷号 29336793）

NDB由于 -DWITH_SYSTEM_LIBS=ON对zlib. （漏洞 #29304517）

删除了在使用 Clang 7编译后 运行 ndb_mgmd 时发现的内存泄漏。（缺陷 #29284643）--config-fileNDB

删除了因使用 extra 引起的clang编译器警告；函数外的字符；这些与 C++98 不兼容。（缺陷号 29227925）

不支持 添加定义为表的 列 。现在尝试这样做会导致错误。（缺陷号 28128849）TIMESTAMP DEFAULT CURRENT_TIMESTAMPNDBALGORITHM=INPLACE

添加了 ndb_restore中缺少的对以下类型集之间转换的支持：

（漏洞#28074988）

使用选项创建的备份中的还原点 SNAPSHOTSTART（请参阅 使用 NDB Cluster Management Client 创建备份）并不总是与纪元边界一致。（漏洞#27566346）

参考资料：另请参阅：Bug #27497461。

当全局模式锁生效时，MAX_EXECUTION_TIME优化器提示和系统变量 都不会max_execution_time 被用于 DDL 语句或针对INFORMATION_SCHEMA表的查询。NDB（漏洞 #27538139）

当多字节字符集用于其中一个或两个的名称时，DDL 操作并不总是对数据库对象（包括数据库和表）正确执行。（缺陷号 27150334）

ndb_import并不总是在退出前释放所有使用的资源。（漏洞 #27130143）

NDBCLUSTER订阅日志打印输出仅提供 2 个字的位图（在大多数情况下包含 8 个字），这使得诊断模式分布问题变得困难。（缺陷号 22180480）

对于某些具有非常大的行和非常大的主键的表，在对这些表之一执行插入或 并发删除时可能会导致数据节点错误。 START BACKUP SNAPSHOTENDSTART BACKUP SNAPSHOTSTART

作为此修复的一部分，ndb_print_backup_file 现在可以读取在非常旧版本的 NDB Cluster（6.3 及更早版本）中创建的备份文件；此外，该实用程序现在还可以读取撤消日志文件。（缺陷 #94654，缺陷 #29485977）

当连接到集群的多个 SQL 节点之一宕机然后重新加入集群，或者一个新的 SQL 节点加入集群时，这个节点没有正确使用数据字典，因此并不总是添加、更改或删除与现有 SQL 节点同步时正确地更新数据库。

现在，在启动时的模式分发期间，SQL 节点将数据节点上的所有数据库与它自己的数据字典中的数据库进行比较。如果发现数据节点上的任何数据库从 SQL 节点的数据字典中丢失，则 SQL 节点使用 ; 在本地安装它CREATE DATABASE；该数据库是使用当前在此 SQL 节点上有效的默认 MySQL 服务器数据库属性创建的。