NDB Cluster APIs：Node.js使用 的版本NDB已经升级到12.20.1。（缺陷号 32356419）

ndbinfo 信息数据库：dict_obj_tree将表 添加ndbinfo信息数据库。此表提供有关 NDB数据库对象的信息，类似于dict_obj_info表中显示的内容，但以分层或树状方式呈现，简化了对象之间关系的查看，例如：表和索引；表空间和数据文件；日志文件组和撤消日志文件。

表的这种视图示例，t1在列上有一个主键，在列上a有一个唯一键b，如下所示：

mysql> SELECT indented_name FROM ndbinfo.dict_obj_tree
    -> WHERE root_name = 'test/def/t1';
+----------------------------+
| indented_name              |
+----------------------------+
| test/def/t1                |
|   -> sys/def/13/b          |
|     -> NDB$INDEX_15_CUSTOM |
|   -> sys/def/13/b$unique   |
|     -> NDB$INDEX_16_UI     |
|   -> sys/def/13/PRIMARY    |
|     -> NDB$INDEX_14_CUSTOM |
+----------------------------+
7 rows in set (0.15 sec)

有关其他信息和示例，请参阅 ndbinfo dict_obj_tree 表。（缺陷号 32198754）

添加了状态变量 Ndb_config_generation，它显示集群正在使用的当前配置的生成编号。这可以作为判断集群配置是否发生变化的指标。（缺陷号 32247424）

NDB Cluster 现在使用 MySQL host_application_signal组件服务来执行 SQL 节点的关闭。（错误#30535835，错误#32004109）

NDB在指数统计计算方面实施了以下两项改进：

有关详细信息，请参阅NDB API 统计计数器和变量。

许多 NDB Cluster 程序现在支持输入密码以NDB 从标准输入加密或解密备份。此处列出了与每个受影响的程序相关的更改：

此外，您可以使ndb_mgm在创建备份时使用加密，方法是使用 --encrypt-backup. 在这种情况下，如果未提供密码，则在调用时会提示用户输入密码 START BACKUP。也可以在文件的 [ndb_mgm]部分中 指定此选项my.cnf。

此外，ndb_mgm 管理客户端的行为和语法START BACKUP略有变化，这样现在可以在ENCRYPT不指定的情况下使用该选项PASSWORD。现在，当用户执行此操作时，管理客户端会提示用户输入密码。

更多信息，请参见刚才提到的 NDB Cluster 程序和程序选项的说明，以及 NDB Cluster 的 在线备份。

打包： 和mysql-cluster-community-server-debugRPM mysql-cluster-commercial-server-debug包分别依赖于 mysql-community-server和 mysql-commercial-server， instead of mysql-cluster-community-server以及 mysql-cluster-commercial-server. （缺陷号 32683923）

打包： RPM 从 NDB 7.6.15 升级到 8.0.22 没有成功，因为文件已从serverRPM 移动到client-pluginsRPM。（缺陷号 32208337）

Linux： 在 Linux 系统上，NDB从中获取的解释内存大小/proc/meminfo以字节而不是千字节为单位提供。（错误#102505，错误#32474829）

Microsoft Windows： 删除了使用 Microsoft Visual Studio 2019 在 Windows 上构建 NDB Cluster 时生成的几个警告。（缺陷号 32107056）

Microsoft Windows： NDB使用 初始化NDB库 ndb_init()，出现错误Failed to find CPU in CPU group。

这个问题是由于 Windows 在将进程分配给 CPU 方面的工作方式：当一台机器上有超过 64 个逻辑 CPU 时，Windows 在启动期间将它们分成不同的处理器组。每个处理器组最多可以容纳 64 个 CPU；默认情况下，一个进程只能分配给一个处理器组。功能 std::thread::hardware_concurrency()用于获取机器上的最大逻辑 CPU 数，但在 Windows 上，此函数仅返回当前进程所属的处理器组中存在的最大逻辑 CPU 数。该值用于为一个数组分配内存，该数组保存有关机器上每个 CPU 的硬件信息。由于阵列只为来自一个处理器组的 CPU 保留有效内存，因此任何存储和检索有关不同处理器组中 CPU 的硬件信息的尝试都会导致阵列绑定读/写错误，从而导致内存损坏并最终导致进程失败。

通过使用GetActiveProcessorCount() 而不是hardware_concurrency() 之前引用的函数修复。（错误#101347，错误#32074703）

Solaris： 在准备NDBFS处理加密备份时， O_DIRECT暂停激活直到文件初始化完成。ext3这导致重做日志文件的初始化在使用带有文件系统 的硬盘驱动器的系统上需要过多的时间

在 Solaris 上，directio使用 代替 O_DIRECT; 在文件初始化之前激活 会导致使用带有文件系统 directio的硬盘驱动器时所需的时间显着增加。UFS

现在我们确保，在具有 的系统上 O_DIRECT，它在文件初始化之前被激活，而在 Solaris 上，它 directio在文件初始化之后继续被激活。（缺陷号 32187942）

NDB Cluster APIs： 源代码中包含的几个 NDB API 编码示例没有释放所有分配的资源。（缺陷号 31987735）

NDB Cluster API： 一些内部字典对象NDB使用内部名称格式，这取决于Ndb对象的数据库名称。这种依赖性已在必要时变得更加明确，否则将被删除。

NDB API 的用户应该知道的 fullyQualified参数 Dictionary::listObjects()仍然以这样的方式工作，即指定它作为 false导致它返回的列表中的对象使用完全限定名称。（缺陷号 31924949）

在某些情况下，影响具有 NDB_STORED_USER特权的用户的查询可以打印到 MySQL 服务器日志而无需重写。现在这样的查询被省略或重写以删除关键字后面的任何文本IDENTIFIED。（缺陷号 32541096）

为数据节点配置参数设置的值 SpinMethod被忽略。（缺陷号 32478388）

DEBUG_FRAGMENT_LOCK 默认情况下启用 编译时调试标志。这导致资源使用量增加 DBLQH，即使对于发布版本也是如此。

DEBUG_FRAGMENT_LOCK 这是通过默认 禁用来解决的。（缺陷号 32459625）

ndb_mgmd现在可以正常退出，SIGTERM就像在管理客户端SHUTDOWN 命令之后一样。（缺陷号 32446105）

当在已被使用的端口上启动时， ndb_mgmd不会抛出任何错误，因为SO_REUSEADDR在 Windows 平台上使用允许多个套接字绑定到相同的地址和端口。

为解决此问题，我们将其替换 SO_REUSEADDRPORT为 SO_EXCLUSIVEADDRUSE，以防止重复使用已在使用的端口。（缺陷号 32433002）

在检测集群的初始系统重启时遇到错误导致 SQL 节点过早退出。（缺陷号 32424580）

在某些情况下，当尝试测量 CPU 暂停时间时，可能会导致经过时间为零。此外，计算非常快速旋转的平均值（例如，100 次循环耗时不到 100 纳秒）可以将纳秒归零。在这两种情况下，这都会导致自旋校准算法因被零除而抛出算术异常。

我们通过修改算法来解决这两个问题，使其在计算平均自旋时间时忽略零值。（缺陷号 32413458）

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

当内部方法 在表中发现给定数据库、表或服务器 ID 的不明确匹配时， 表和数据库名称在写入mysqld错误日志的消息中的格式不正确。（缺陷号 32393245）Ndb_rep_tab_reader::scan_candidates()ndb_replication

一些带有嵌套推送连接的查询没有被正确处理。（缺陷号 32354817）

当ndb_mgmd分配节点 ID 时，它会通读配置以找到合适的 ID，从而导致在执行主机名查找时保持互斥锁。因为网络地址解析可能需要大量时间，所以在执行网络操作时持有这样的互斥锁或锁不是好的做法。

通过在持有互斥锁的同时构建已配置节点的列表，然后使用该列表执行主机名匹配和其他逻辑来解决此问题。（缺陷号 32294679）

模式分发参与者在向表写入回复后未能启动全局检查点 ndb_schema_result，这导致协调器在收到参与者通知其结果的事件之前出现不必要的延迟。（缺陷号 32284873）

当在具有新 IP 地址的新机器上重新启动节点时， ndb_mgmd 中使用的全局 DNS 缓存会导致查找过时，这意味着该节点无法分配节点 ID。

此问题已通过以下更改得到解决：

（缺陷号 32264914）

ndb_restore在使用未知或无效参数启动时生成了一个核心文件。（缺陷号 32257374）

自动同步检测到 NDB 字典中存在模拟外键表，并尝试在 MySQL 服务器的数据字典中重新创建它们，尽管这些应该保留在 NDB 字典内部，而不是暴露给 MySQL 服务器。为了解决这个问题，我们现在确保 NDB Cluster 自动同步机制忽略任何此类模拟表。（缺陷号 32245636）

改进了与集群配置数据处理相关的资源使用。（缺陷号 32224672）

从显示连接时客户端版本号的ndb_mgmd 中删除了剩余的调试打印输出 。（缺陷号 32210216）

参考：这个问题是 Bug #30599413 的回归。

用于处理节点故障的备份中止协议对于单线程数据节点 ( ndbd ) 无法正常运行。（缺陷号 32207193）

ORDER BY使用index 访问方法（和不使用 ） 从下推连接检索排序结果时 filesort，SQL 节点有时会意外终止。（错误号 32203548）

重做日志初始化的日志记录显示日志部分索引而不是日志部分编号。（缺陷号 32200635）

由于使用扩展信号内存作为临时存储，信号数据被覆盖（和丢失）。现在在这种情况下，不会以这种方式使用扩展信号存储器。（缺陷号 32195561）

当 时 ，每个节点的默认分区数（在ndb_desc输出中 显示为新配置更改 LDM 线程数，从而更改默认分区数。现在在这种情况下，我们确保每次数据节点加入或离开集群时重新计算每个节点的默认分区数。 ClassicFragmentation = 1PartitionCount

ClassicFragmentation当设置为 0 时，这在 NDB 8.0.23 及更高版本中不是问题。 （漏洞 #32183985）

内部功能Ndb_ReloadHWInfo()负责更新主机上所有 CPU 的硬件信息。对于没有三级缓存信息的 Linux ARM 平台，这为三级缓存 ID 分配了一个套接字 ID，但未能记录全局变量的值， num_shared_l3_caches在创建连接到共享三级缓存的 CPU 列表时需要该值. （缺陷号 32180383）

当尝试在同一台主机上运行两个管理节点并使用相同的端口号时，用户并不总是很清楚为什么它们没有启动。现在在这种情况下，除了向错误日志写入一条消息外， 还会向控制台写入一条错误消息Same port number is specified for management nodes node_id1and node_id2(or) they both are using the default port number on same host host_name问题的根源更加明显。（缺陷号 32175157）

为ndb_mgmd和ndb_config 添加了一个--cluster-config-suffix选项 ，用于在内部测试中覆盖默认组后缀。（缺陷号 32157276）

当配置中的某些主机名未解析并且客户端尝试分配从主机连接的节点 ID 时，管理服务器返回主机名匹配的错误状态，该主机的主机名解析为环回地址，并出现错误Could not alloc node id在 <host>:<port>：从错误的主机 ip 127.0.0.1 完成的 ID X 连接，预期为 <unresolvable_host>（查找失败）。

这导致连接客户端无法分配节点 ID。

这个问题通过重写内部 match_hostname() 函数来解决，这样它就包含请求客户端地址如何匹配配置的主机名的所有逻辑，并且它首先检查配置的主机名是否可以解析；如果不是，它现在返回一个特殊错误，以便客户端收到一个错误，指示可以重试节点 ID 分配。新错误是Could not alloc node id at <host>:<port>: No configured host found of node type <type> for connection from ip 127.0.0.1. 一些主机名目前无法解析。可以重试。（缺陷号 32136993）

调用失败时 ，内部函数 ndb_socket_create_dual_stack()不会关闭新创建的套接字 。ndb_setsockopt()（缺陷号 32105957）

NDB 7.6 中的本地检查点 (LCP) 机制发生了变化，因此它还可以检测空闲片段——即自上次 LCP 以来未更改的片段，因此不需要磁盘元数据更新。然后 LCP 机制可以立即着手处理下一个片段。当存在大量此类空闲碎片时，仅循环遍历这些碎片所需的 CPU 消耗就变得非常显着，从而导致用户交易出现延迟峰值。

在处理的每个这样的空闲片段之间已经插入了 1 毫秒的延迟。后来的测试表明这个间隔太短了，而且我们通常并不像我们以前认为的那样急于完成这些空闲片段。

如果没有指示迫切需要完成 LCP 的重做警报，此修复会将空闲片段延迟时间延长至 20 毫秒。在低重做警报状态的情况下，我们等待 5 毫秒，而对于更高的警报状态，我们回退到 1 毫秒延迟。（缺陷号 32068551）

参考资料：另请参阅：Bug #31655158、Bug #31613158。

创建NDB表时，它在全局字典缓存中失效，但这是不必要的。此外，拥有一个存在于全局字典缓存中的表实际上有利于后续使用新表，因为它可以在表缓存中找到而无需执行到NDB. （缺陷号 32047456）

当ndb_mgmd进程尝试开始使用 PortNumber已在使用的端口时， 没有提供明确的错误消息 。（缺陷号 32045786）

NDB关闭表 时出现两个问题：

（错误#32018394，错误#32357856）

删除了大量与NdbDictionaryImpl. （缺陷号 31960757）

检查内部错误代码时执行了不必要的转换。（缺陷号 31930166）

NDB继续使用文件系统路径来确定要打开或执行 DDL 的表的名称，尽管事实上它实际上不再使用文件来进行这些操作。这需要在字符集之间进行不必要的转换，处理 MySQL 特定的文件系统编码和解析。此外，这些操作的结果存储在固定大小的缓冲区中，每个实例都不必要地占用了数百字节的内存。由于要使用的数据库和表名称已经可以 NDB通过其他方式使用，因此在大多数情况下可以（并且已经）删除此翻译。（缺陷号 31846478）

与对象计数相关的内部统计数据的生成 NDB被发现导致交易延迟以每秒非常高的交易率增加，这是由于返回过多数量的已释放NDB对象引起的。（缺陷号 31790329）

NDBNDB_STORED_USER 在二进制日志线程关闭和重新启动期间，在响应尝试更改分布式用户（即具有特权的用户）的权限时表现出不可预测的行为。我们通过确保用户在分发不成功时收到明确的警告Could not distribute ACL change to other MySQL servers 来解决这个问题。此修复程序还改进了许多 mysqld日志消息。（缺陷号 31680765）

ndb_restore在重放删除 blob 值的备份日志时遇到间歇性错误；这是由于删除包含 blob 一个或多个值的主表行时删除了 blob 部分。这是通过修改 ndb_restore以使用异步 API 进行 blob 删除来解决的，这不会在删除 blob 主表行时触发 blob 部分删除（与同步 API 不同），因此主表的删除日志事件仅删除来自主表的行。（缺陷号 31546136）

当表创建模式事务准备好时，表处于状态，并在模式事务提交到块时TS_CREATING更改为 状态。如果在提交模式事务时充当 协调器的节点发生故障，则另一个节点开始接管协调器。处理此节点故障时会采取以下操作： TS_ACTIVEDBDIHDBDIH

这些动作多次异步执行，交错时可能会导致竞争条件。因此，故障节点的副本所在的副本列表变得不确定，并且可能在恢复节点（即新协调器）和其他 DIH参与节点之间有所不同。这种差异违反了了解在其他参与者的故障节点恢复过程中可以找到故障节点副本的列表的要求。

为了解决这个问题，移动活动表副本现在不仅涵盖处于TS_ACTIVE状态的表，还包括处于 TS_CREATING（准备好的）状态的表，因为准备好的模式事务总是前滚。

此外，正在中止的表创建模式事务的状态现在从 TS_CREATING或更改TS_IDLE为 TS_DROPPING，以避免出现任何竞争条件。（缺陷号 30521812）

START BACKUP SNAPSHOTSTART WAIT STARTED从用户的角度来看，可以在备份还原点之前将控制权交还给用户；也就是说，Backup started通知是在等待同步全局检查点 (GCP) 边界之前发送的。这意味着在收到通知后提交的事务可能包含在恢复的数据中。

为了解决这个问题，START BACKUP现在只在 GCP 真正启动后才向客户端发送一个通知，通知备份已经启动。（漏洞#29344262）

从以前的版本升级到 NDB Cluster 8.0 包括模式分发机制的升级，作为其中一部分，ndb_schema表被删除并重新创建，导致连接到集群的所有 MySQL 服务器重新启动其二进制日志注入器线程，从而导致gap 事件写入二进制日志。由于线程重启在所有 MySQL 服务器上同时发生，因此没有二进制日志跨越执行模式分发功能升级的时间，这会破坏 NDB Cluster Replication。

通过添加对优雅地重构架构分布表的支持，同时允许注入器线程继续处理来自集群的更改，此问题已得到修复。这是通过处理 DDL 事件通知 DROP TABLE来临时关闭对模式分发的支持并开始定期检查以重新创建表来实现的。再次成功创建表后，将关闭常规检查并重新打开对模式分发的支持。

NDB现在还会自动检测何时 ndb_apply_status删除表并重新创建它。删除和重新创建在二进制日志中留下一个间隙事件，这在复制设置中导致副本 MySQL 服务器停止应用来自源的更改，直到复制通道重新启动（参见 ndb_apply_status 表）。

此外，执行架构分发升级所需的最低版本提高到 8.0.24，这可以防止自动触发架构分发升级，直到所有连接的 API 节点都支持新的升级程序。

有关更多信息，请参阅 NDB Cluster 复制模式和表。（错误#27697409，错误#30877233）

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

修复了尝试 NDB使用 GCC 6 构建时发现的一些问题。（错误 #25038373）

当每个 LDM 使用超过 1 个日志部分时，基于重做日志使用情况计算重做警报状态过于激进，因此不正确。