重要变化： 作为从 MySQL 8.0.21 和 NDB 8.0.21 开始的术语变化的一部分， ndb_slave_conflict_role系统变量现已弃用，并被替换为 ndb_conflict_role.

此外，一些状态变量已被弃用并正在被替换，如下表所示：

同样作为这项工作的一部分， ndbinfo.table_distribution_status 表的tab_copy_status列值 ADD_TABLE_MASTER和 ADD_TABLE_SLAVE已弃用，并分别由和ADD_TABLE_COORDINATOR替换 ADD_TABLE_PARTICIPANT。

最后，更新--help了一些 NDB 实用程序（例如ndb_restore ）的输出。（缺陷号 31571031）

NDB 客户端程序： 从此版本开始生效，MySQL NDB Cluster 自动安装程序 ( ndb_setup.py ) 已从 NDB Cluster 二进制文件和源代码分发中删除，不再受支持。（缺陷号 32084831）

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

作为之前在 NDB 8.0 中完成的工作的一部分，作为NDBNDB 字典中表的表示与其在 MySQL 数据字典中的对应表之间的自动同步的一部分执行的元数据检查已扩展为包括，除了表级属性、列、索引和外键的属性。（在执行CREATE TABLE 语句和打开NDB表时，调试 MySQL 服务器也会进行此检查。）

作为这项工作的一部分，在 NDB 字典和 MySQL 数据字典中发现的对象属性之间的任何不匹配现在都会写入 MySQL 错误日志。错误日志消息包括属性的名称、它在 NDB 字典中的值以及它在 MySQL 数据字典中的值。如果对象是列、索引或外键，则对象的类型也会在消息中指明。

该ThreadConfig 参数已扩展为两种新的线程类型，即查询线程和恢复线程，用于横向扩展 LDM 线程。查询线程数必须是 LDM 线程数的倍数，最多为 LDM 线程数的 3 倍。

现在也可以 通过将这些参数中的一个或两个设置为 0 ThreadConfig来将main和线程合并为一个线程。rep

当这些参数之一设置为 0 而另一个保持设置为 1 时，生成的组合线程被命名为 main_rep。当两者都设置为 0 时，它们与recv线程组合（假设 recv为 1），这个组合线程被命名为 main_rep_recv。这些线程名称是在检查 信息数据库 中的threads表 时显示的那些。ndbinfo

此外，增加了一些现有线程类型的最大值。新的最大值是：LDM 线程：332；TC线程：128；接收线程：64；发送线程：64；主线程：2.（查询线程和恢复线程的最大值各为 332。）其他线程类型的最大值与之前的 NDB Cluster 版本保持不变。

与此工作相关的另一个更改导致 NDB在使用超过 32 个块线程时使用互斥锁来保护作业缓冲区。这可能会导致性能略有下降（大约 1% 到 2%），但也会导致非常大的配置所使用的内存量减少。例如，以前使用 2 GB 作业缓冲内存的 64 线程设置现在应该只需要大约 1 GB。在我们的测试中，这导致在执行非常复杂的查询时整体改进（大约 5%）。

有关详细信息，请参阅ThreadConfig前面讨论的参数的自变量和 ndbinfo.threads表格的说明。

此版本通过实现新的数据节点配置参数 ，增加了为多线程数据节点 ( ndbmtdAutomaticThreadConfig ) 自动配置线程的可能性。设置为 1 时NDB，根据应用程序可用的处理器数量自动设置线程分配。如果系统不限制处理器的数量，您可以通过设置 NumCPUs为所需的数量来实现。自动线程配置使得无需为 ThreadConfig或 MaxNoOfExecutionThreads in设置任何值config.ini；如果 AutomaticThreadConfig启用，则不使用这些参数中的任何一个的设置。

作为这项工作的一部分，一组提供有关硬件和 CPU 可用性以及 NDB 数据节点使用情况的信息的表已添加到ndbinfo 信息数据库中。此处列出了这些表格以及每个表格提供的信息的简要说明：

并非所有列出的表在 NDB Cluster 支持的所有平台上都可用：

在块中添加统计信息， DBLQH用于跟踪密钥查找和扫描的使用，以及跟踪来自DBTC 和的查询DBSPJ。通过检测负载高但实际上不需要减少每次实时中断扫描的行数的情况，而不是检查作业缓冲区队列的大小来决定要扫描多少行，这使得当没有 CPU 拥塞时，可以扫描更多行。这有助于在处理高负载时提高性能和实时行为。

引入了一种处理表分区和碎片的新方法，这样可以独立于重做日志部分的数量来确定给定数据节点的本地数据管理器 (LDM) 的数量，并且 LDM 的数量现在可以高度可变. NDB当 ClassicFragmentation 作为这项工作的一部分实现的数据节点配置参数设置为false. 完成后，不再使用 LDM 的数量来确定为每个数据节点的表创建多少个分区；相反， PartitionsPerNode 同样在此版本中引入的参数现在决定了这个数字，现在用于计算一个表应该有多少片段。

当ClassicFragmentation有其默认值true时，则使用传统的使用 LDM 数量的方法来确定一张表应该有多少分片。

有关详细信息，请参阅 多线程配置参数 (ndbmtd)。

macOS： 删除了为 Mac OS X 构建时出现的一些编译器警告NDB。（缺陷号 31726693）

Microsoft Windows：从 storage\ndb\src\kernel\blocks\dbacc\dbaccmain.cpp. （缺陷号 23130016）

Solaris： 由于源代码级错误，atomic_swap_32() 应该指定但实际上并未用于 NDB Cluster 的 Solaris 构建。（缺陷号 31765608）

NDB Cluster APIs： 删除了strlen()的实现NdbDictionary 和相关内部类中的冗余使用。（缺陷 #100936，缺陷 #31930362）

调用 时disk_page_abort_prealloc()，忽略来自该内部函数的回调，因此LQHKEYREQ 无需等待即可继续删除信号的操作记录。这使得表在回调完成之前可能会被删除，从而导致PGMAN从磁盘检索页面时失败。

为了避免这种情况，我们为表添加了一个额外的使用计数，特别是对于这个页面缓存未命中；一旦页面缓存未命中返回，此计数就会减少。这意味着我们保证从磁盘读取返回时该表仍然存在。（缺陷号 32146931）

创建表时，可能会在下一个本地检查点期间过早地为表的片段设置检查点。这意味着当 LCP 完成时，准备阶段 LCP 写入仍在执行，这可能导致ALTER TABLE刚创建的表上的后续语句出现问题。现在我们等待任何潜在的准备阶段 LCP 写入在 LCP 被认为完成之前完成。（缺陷号 32130918）

使用索引统计信息支持的最大索引键大小（3056 字节）会导致数据节点出现缓冲区问题。（缺陷号 32094904）

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

NDB现在更喜欢 CLOCK_MONOTONIC在 Linux 上通过频率更改进行调整但在挂起期间不更新。在 macOS 上， NDB使用 CLOCK_UPTIME_RAWwhich 是一样的，只是它不受任何调整的影响。

此外，在初始化NdbCondition 要使用的单调时钟时，直接从 获取 NdbTick，而不是重新执行NdbTick. （缺陷号 32073826）

--decrypt在 big-endian 系统上使用该选项运行时， ndb_restore意外终止（缺陷号 32068854）

当数据节点接收线程发现作业缓冲区太满而无法接收时，没有采取任何措施来确保下次检查时，它会在先前停止的同一点恢复从传输器接收。（缺陷号 32046097）

在使用ndb_restore工具 恢复的表的自动同步过程中，元数据检查失败。这是一个与索引相关的定时问题，在以下两种选表自动同步的场景中发现：

（缺陷号 32004637）

通过在数据结构中注册受影响的内核块和需要为每个内核块调用的发送函数而不是每次都查找此信息来优化打包信号的发送。（缺陷号 31936941）

当两个数据定义语言语句（一个在数据库上，另一个在同一架构中的表上）并行运行时，可能会发生死锁。影响数据库的 DDL 语句首先获取了全局模式锁，但在它获取数据库的元数据锁之前，影响表的语句获取了模式的意向独占元数据锁。因此，表 DDL 语句等待全局模式锁将其在表上的元数据锁升级为独占锁，而数据库 DDL 语句等待数据库上的独占元数据锁，从而导致死锁。

已知会发生涉及表空间和表的类似类型的死锁；NDB 已经检测到并解决了该问题。当前修复扩展了该逻辑以处理数据库和表，以解决该问题。（缺陷号 31875229）

由于未初始化的变量，Clang 8 发出警告。（缺陷号 31864792）

为插入获取的空页未收到日志序列号。这是必要的，以防页面以前被使用过，因此需要在再次使用之前执行撤消日志。（缺陷号 31859717）

ALTER TABLE ... ADD PARTITION拒绝在完全复制的表上 执行就地语句的尝试时没有提供任何理由 。（缺陷号 31809290）

当主节点记录的 GCI 比重启失败的节点更新时，后者的后续重启无法执行，因为它无法恢复规定的 GCI。（缺陷号 31804713）

当使用 3 或 4 个片段副本时，一次可以添加多个节点，这意味着 DBLQH和 DBDIH可以具有基于最多相差 3（即MAX_REPLICAS- 1）的片段副本数的分布密钥，而不是比只有 1。（缺陷 #31784934）

在从下DBLQH一个本地查询处理程序接收到信号之前， ABORT信号可能会到达 。现在在这种情况下，乱序 信号将被忽略。（缺陷号 31782578）DBTCLQHKEYREFABORT

NDB没有正确处理 ALTER TABLE ... COMMENT="..."语句未指定 的情况ALGORITHM=COPY。（缺陷号 31776392）

在某些情况下，可能会错过片段的撤消日志记录的终点。（缺陷号 31774459）

ndb_print_sys_file无法与sysfileNDB 8.0.18 中引入的格式版本 2 一起正常工作。（缺陷号 31726653）

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

DBLQH无法处理具有相同事务 ID 的相同操作记录来自不同事务协调器的情况。这导致锁定的行在节点故障后持续存在，从而阻止节点恢复完成。（缺陷号 31726568）

有可能DBDIH接收到具有给定 ID 的本地检查点以恢复，而实际上使用了后来的 LCP，但是在这种情况下执行部分 LCP 时，该DIH块与所使用的 LCP 的 ID 不完全同步。（缺陷号 31726514）

在大多数情况下，在搜索哈希索引时，该行用于读取主键，但当该行尚未提交时，可能会从复制行中读取主键。如果该行已被删除，则不能再用于读取主键。以前在这种情况下，主键被视为 NULL，但这可能导致使用未初始化的数据进行比较。

现在，当发生这种情况时，仅当该行未被删除时才进行比较；否则在串行队列中的操作中检查该行。如果没有操作具有主键，那么任何比较都可以报告为不相等，因为并行队列中没有条目可以重新插入该行。这需要检查，因为如果串行队列中的条目是插入，则必须识别此操作的主键，以防止两次插入相同的主键。（缺陷号 31688797）

与写入重做日志记录一样，当当前用于写入全局检查点记录的文件变满时，写入切换到下一个文件。在新文件实际准备好接收记录之前，不应该发生这种切换，但没有进行检查以确保情况确实如此。这可能导致计划外的数据节点关闭使用ndb_restore从备份恢复数据。（缺陷号 31585833）

当块不再需要共享全局内存时，它的释放DBSPJ现在比以前更快。（缺陷号 31321518）

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

使用kill -9 停止单个节点组中 4 个节点中的 3 个节点会 导致集群意外关闭。为了防止这种情况在这种情况下发生，NDB现在要确保仲裁检查将任何没有节点故障的节点组视为完全可行。（缺陷号 31245543）

多线程索引构建有时会尝试使用不允许使用的内部函数。（缺陷号 30587462）

在向集群添加新数据节点时，以及管理节点使用更新的配置文件重新启动时，一些数据节点意外终止并出现错误 virtual void TCP_Transporter::resetBuffers(): Assertion `!isConnected()' failed。（缺陷号 30088051）

对于设置为 0的外键的父表， 无法执行TRUNCATE TABLE或执行。 （错误 #97501，错误 #3050​​9759）DROP TABLEforeign_key_checks

优化了内部 NdbReceiver::unpackNdbRecord()方法，该方法用于将从数据节点检索的行从 packed wire 格式转换为 NDB API 行格式。在更改之前，执行连接的 CPU 使用率大约有 13% 发生在该方法中；这减少到大约 8%。（缺陷 #95007，缺陷 #29640755）