不相容的变化；NDB 磁盘数据： 由于磁盘文件格式的变化，--initial在升级到此版本或从该版本降级时，需要重新启动每个数据节点。

重要变更；NDB 磁盘数据： NDB Cluster 通过实施部分本地检查点 (LCP)，改进了节点重启时间和更大数据集的整体性能。在此版本之前，LCP 总是制作整个数据库的副本。

NDB现在支持写入单个记录的 LCP，因此不再严格要求 LCP 写入整个数据库。因为在恢复时，仍然需要完全恢复数据库，所以策略是在每个 LCP 保存所有记录的四分之一，以及写入自上次 LCP 以来更改的记录。

此版本中引入了与此更改相关的两个数据节点配置参数：（ EnablePartialLcp 默认true或启用）启用部分 LCP。启用部分 LCP 时， RecoveryWork控制分配给 LCP 的空间百分比；它随着重新启动期间必须在 LCP 上执行的工作量的增加而增加，而不是在正常操作期间执行的工作量。提高此值会导致 LCP 在正常操作期间需要写入较少的记录，从而减少通常的工作量。提高此值还意味着重新启动可能需要更长的时间。

此外，默认值 StartPartitionedTimeout 从 60000 更改为 0。

此版本还弃用了数据节点配置参数 BackupDataBufferSize, BackupWriteSize, 和 BackupMaxWriteSize; 这些现在可以在未来的 NDB Cluster 版本中删除。（缺陷号 27308632）

重要更改： 添加了ndb_perror实用程序以获取有关 NDB Cluster 错误代码的信息。这个工具取代了 perror --ndb；perror的 --ndb选项 现在已弃用，并在使用时发出警告；该选项可能会在未来的 NDB 版本中被删除。

有关详细信息，请参阅ndb_perror — 获取 NDB 错误消息信息。（错误#81703、错误#81704、错误#23523869、错误#23523926）

参考资料：另请参阅：Bug #26966826、Bug #88086。

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

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

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

此外，现在通过以下两个标准 来区分“ ThreadConfig ”NDB可访问的线程类型：

有关其他信息，请参阅手册中的参数说明。（错误#25835748，错误#26928111）

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

（缺陷号 25428560）

添加了 ndbinfo.error_messages表格，该表格提供了有关 NDB Cluster 错误的信息，包括错误代码、状态类型、简要描述和分类。这样就可以在mysql客户端（或其他MySQL客户端程序）中使用SQL获取错误信息，像这样：

mysql> SELECT * FROM ndbinfo.error_messages WHERE error_code='321';
+------------+----------------------+-----------------+----------------------+
| error_code | error_description    | error_status    | error_classification |
+------------+----------------------+-----------------+----------------------+
|        321 | Invalid nodegroup id | Permanent error | Application error    |
+------------+----------------------+-----------------+----------------------+
1 row in set (0.00 sec)

刚刚显示的查询提供的信息与通过在命令行上发出ndb_perror 321或（现已弃用）perror --ndb 321获得的信息等效。（缺陷 #86295，缺陷 #26048272）

ThreadConfig现在有一个附加nosend参数，可用于防止main、 ldm、rep或 tc线程协助发送线程，方法是将给定线程的此参数设置为 1。默认情况下， nosend为 0。它不能与刚刚列出的类型以外的线程一起使用。

将扫描作为推送连接执行时，所有实例 DBSPJ都参与单个查询的执行；其中一些收到来自同一查询的多个请求。通过启用单个 SPJ 请求来处理一组要扫描的根片段，这种情况得到改善，这样只有单个 SPJ 请求被发送到 DBSPJ每个节点上的每个实例，并且每个片段分配批大小，多片段扫描可以获得更大的总批量大小，允许在内部完成一些调度优化DBSPJ，它可以一次扫描一个片段（给它总批大小分配），使用较小的子批并行扫描所有片段，或两者的某种组合。

由于此更改的效果通常是需要更少的 SPJ 请求和实例，因此在许多情况下应该改进下推连接的性能。

作为 ndbmtd 正在进行的优化批量 DDL 性能工作的一部分，现在可以通过增加 DDL 操作的批量数据部分的批量大小来获得性能改进，这些操作使用扫描处理一个片段或一组片段中的所有数据. 通过设置此处列出的相应数据节点配置参数，现在可以为唯一索引构建、外键构建和在线重组配置批量大小：

对于刚刚列出的每个参数，默认值为 64，最小值为 16，最大值为 512。

增加适当的批量大小可以帮助分摊线程间和节点间延迟，并利用更多并行资源（本地和远程）来帮助扩展 DDL 性能。

以前，数据节点LGMAN内核块串行处理撤销日志记录；现在这是并行完成的。该rep线程将撤消记录移交给本地数据处理程序 (LDM) 线程，等待 LDM 完成应用一条记录，然后再获取下一条记录；现在rep线程不再等待，而是立即处理下一条记录和 LDM。

与这项工作直接相关的功能没有用户可见的变化；此性能增强是 NDB 7.6 中完成的工作的一部分，以改进对部分本地检查点的撤消长处理。

应用撤消日志时，表 ID 和片段 ID 是从页面 ID 中获取的。这是通过PGMAN使用额外的 PGMAN工作线程读取页面来完成的，但是在应用撤消日志时，有必要再次读取页面。

这在使用 O_DIRECT（参见 参考资料ODirect）时变得非常低效，因为页面没有缓存在 OS 内核中。

从页面 ID 到表 ID 和片段 ID 的映射现在是使用范围标头包含的关于给定范围中使用的页面的表 ID 和片段 ID 的信息完成的。由于区段页面始终存在于页面缓存中，因此执行映射不需要额外的磁盘读取，并且可以使用现有TSMAN数据结构读取信息。

在ndb_mgm客户端中 添加了NODELOG DEBUG 命令，以提供对数据节点调试日志记录的运行时控制。导致数据节点将额外的调试信息写入其节点日志，就像节点已经启动一样。 禁用额外的日志记录。 NODE DEBUG ON--verboseNODELOG DEBUG OFF

添加了LocationDomainId管理、数据和 API 节点的配置参数。在云环境中使用 NDB Cluster 时，您可以设置此参数以将节点分配给给定的可用性域或可用性区域。这可以通过以下方式提高性能：

该参数取 0 到 16 之间的整数值，默认为 0；使用 0 与不 LocationDomainId设置相同。

重要更改：ndb_top 的--passwd选项 现已弃用。它在 NDB 7.6.5 中被删除（并替换为（漏洞 #88236，漏洞 #20733646）--password

参考资料：另请参阅：Bug #86615、Bug #26236320、Bug #26907833。

NDB 磁盘数据： 一种ALTER TABLE在表存储格式之间切换MEMORY并 DISK始终对所有列执行的数据。对于从表继承存储格式的列，这是不正确的；列的存储类型没有改变。

例如，此语句创建一个表 t1，其列c2使用内存存储，因为该表隐式这样做：

CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 INT) ENGINE NDB;

此处显示的ALTER TABLE语句预计会导致c2存储在磁盘上，但未能这样做：

ALTER TABLE t1 STORAGE DISK TABLESPACE ts1;

同样，从它所属的表继承其存储格式的磁盘列没有被更改格式ALTER TABLE ... STORAGE MEMORY。

这两种情况现在作为复制更改执行，受影响列的存储格式现在已更改。（漏洞#26764270）

解析NDB_TABLE修饰符的错误可能会导致内存泄漏。（漏洞#26724559）

添加DUMP代码 7027 以方便测试与本地检查点相关的问题。有关详细信息，请参阅 DUMP 7027。（漏洞#26661468）

先前的修复旨在改进事务协调器中节点故障处理的日志记录，包括在正常操作中可能发生的事务日志记录，这使得生成的日志不必要地冗长。在这种情况下，此类正常事务不再写入日志。（缺陷号 26568782）

参考资料：此问题是 Bug #26364729 的回归。

由于配置文件错误，CPU 锁定功能在 Linux 平台的构建中不可用。（缺陷号 26378589）

DUMP用于 内核块的 某些代码LGMAN在用于属于 DBTUX. 现在已经为它们分配了适当范围内的符号常量和数字（10001、10002 和 10003）。（漏洞 #26365433）

内核块中的节点故障处理DBTC由许多并发执行的任务组成，并且所有这些任务都必须在 TC 节点故障处理完成之前完成。此修复扩展了日志记录覆盖范围以记录每个任务何时完成以及哪些任务仍然存在，包括以下改进：

（漏洞#26364729）

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

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

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

在TRUNCATE TABLE一个 NDB表上，它的 AUTO_INCREMENTID 没有在不执行二进制日志记录的 SQL 节点上重置。（漏洞 #14845851）

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

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

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

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

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

当在查询计划中表示物化半连接时，MySQL 优化器插入额外的QEP_TAB和 JOIN_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。

DBTC内核块可能会在未准备好的状态下接收 信号TCRELEASEREQ。现在，在这种情况下，它会响应一条 TCRELEASECONF消息，随后的行为就像 API 连接失败一样。（漏洞 #87838，漏洞 #26847666）

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

当数据节点配置为将线程锁定到 CPU 时，它在启动期间失败并显示Failed to lock tid。

这是上一个问题修复的副作用，它根据可用的 glibc. 仅在响应未被数据节点使用的内部 NDB API 调用（并且只能通过内部 API 调用访问）glibc 时才会遇到要防范的特定问题。Ndb_UnlockCPU()当前修复为数据节点启用 CPU 锁定，并在使用受影响的glibc版本时仅为相关 API 调用禁用它。（漏洞 #87683，漏洞 #26758939）

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

ndb_topncurses无法在库未定义 的平台上构建stdscr。现在这些平台要求 tinfo包含该库。（缺陷 #87185，缺陷 #26524441）

LCP_COMPLETE_REP完成本地检查点后，每个节点都会向集群中的每个其他节点 发送 信号；一个节点在收到所有其他节点已发送此信号的通知之前，不会认为 LCP 已完成。由于 LCP 协议中的一个小缺陷，如果此消息从主节点以外的另一个节点延迟，则有可能在一个或多个节点完成正在进行的一个节点之前启动下一个 LCP；这导致了 LCP_COMPLETE_REP来自先前 LCP 的信号与来自当前 LCP 的此类信号混淆的问题，进而导致节点故障。

为了解决这个问题，我们现在确保在响应任何 TCGETOPSIZEREQ启动新 LCP 的信号之前之前的 LCP 已经完成。（错误#87184，错误#26524096）

构建使用时 NDB Cluster 没有成功编译 WITH_UNIT_TESTS=OFF。（缺陷 #86881，缺陷 #26375985）

用于打开文件的本地检查点处理的最新改进在 OM_CREATEWindows 平台上无法正常工作，系统尝试创建一个新文件，但如果它已经存在则失败。（缺陷 #86776，缺陷 #26321303）

发送 START_FRAG_REQ信号时潜在的百倍信号扇出可能导致节点故障，因为在重启期间尝试执行本地检查点时，启动阶段 5 中出现作业缓冲区已满错误。（错误#86675，错误#26263397）

参考资料：另请参阅：Bug #26288247、Bug #26279522。

-DWITHOUT_SERVER=1当仅用于构建客户端库 时，NDB Cluster 的编译失败 。（漏洞 #85524，漏洞 #25741111）

该NDBFS块的OM_SYNC 标志旨在确保用于给定文件的所有 FSWRITEREQ 信号都是同步的，但被不支持的平台忽略O_SYNC，这意味着该功能在这些平台上无法正常运行。现在同步标志用在那些不支持的平台上O_SYNC。（错误#76975，错误#21049554）