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

NDB Cluster APIs： 将方法添加 NdbScanFilter::setSqlCmpSemantics() 到 NDB API。以前， NdbScanFilter始终视为NULL等于自身，因此 NULL == NULL计算为 Boolean TRUE；这不符合 SQL 标准，它要求NULL == NULL 返回NULL. 新方法可以覆盖传统行为，并NULL在给定NdbScanFilter 实例的生命周期内强制执行符合 SQL 的比较。

有关详细信息，请参阅 MySQL NDB Cluster API 开发人员指南中的 NdbScanFilter::setSqlCmpSemantics()。

ndb_restore现在支持 NULL和NOT NULL列之间的转换，如下：

有关详细信息，请参阅指示的 ndb_restore选项的描述。（缺陷号 32702637）

添加了PreferIPVersion 配置参数，该参数控制 DNS 解析器对 IPv4 ( 4) 或 IPv6 ( 6)的寻址首选项，4为默认值。对于所有 TCP 连接，此参数必须相同；因此，您应该只在 [tcp default]集群全局配置文件的部分中设置它。（缺陷号 32420615）

打包： 手册ndb-common页已删除，其中包含的信息已移至其他手册页。（缺陷号 32799519）

打包： mysqlbinlog实用程序未包含在 NDB Cluster Docker 映像中。（缺陷号 32795044）

NDB 复制：NDB_STORED_USER在参与 NDB 复制的 SQL 节点上 使用我们通过确保 在这种情况下执行 ACL 操作时正确处理log_slave_updates 原始server_id（缺陷号 32832676）

NDB 复制： 启动具有 255 个 SQL 节点的集群时，一些 mysqld进程没有正确初始化模式分布。这导致二进制日志设置失败，结果是 SQL 节点永远无法运行。订阅模式更改时发生此错误；NdbEventOperation为 设置mysql.ndb_schema失败。另外，一个MySQL Server还需要为 mysql.ndb_schema_result表设置一个订阅，所以每个MySQL Server需要两个资源。

为解决此问题， MaxNoOfSubscriptions 配置参数的有效默认值现在被视为，而不是。（缺陷号 32380993）2 * MaxNoOfTables + 2 * [number of API nodes]2 * MaxNoOfTables

NDB Cluster API： Node.js 适配器并不总是正确处理字符集和排序规则编号。（缺陷号 32742521）

NDB Cluster API：在 MGM API 中 添加了NDB_LE_EventBufferStatus3日志事件类型这是将总字节数、最大字节数和分配字节数作为 64 位值处理 Ndb_logevent_type的类型的扩展 NDB_LE_EventBufferStatus

作为此修复的一部分，服务器系统变量的最大值 ndb_eventbuffer_max_alloc 增加到 9223372036854775807 (2 ⁶³ - 1)。

有关详细信息，请参阅 Ndb_logevent_type 类型。（缺陷号 32381666）

NDBCLUSTER如果它被称为视图或表子查询的一部分，则可推送到引擎的条件不会被推送到表中 。 （缺陷号 32924533）

由于ndbxfrm包含库 ，使用动态链接的 Docker 的 RPM 构建NDB未完成 。现在ndbxfrm改用内部和 库。 ndbclientndbgeneralndbportlib

作为此修复的一部分，ndb_restore现在还链接到ndbgeneral和 ndbportlib。（缺陷号 32886430）

NDB现在使用std::min() andstd::max()代替它自己的内部宏来确定两个数字的最小值和最大值。（缺陷号 32854692）

ndb_restore 打印的一些错误消息 试图访问已经关闭的事务以获取错误信息，从而导致计划外退出。（缺陷号 32815725）

NDB错误 418（Out of transaction buffers in LQH...）、419（Out of signal memory...）和 805（Out of attrinfo records in tuple manager... ） 的错误消息都提到 increasing LongSignalMemory，尽管有没有该名称的配置参数。所有这三个错误消息都已更正为引用 LongMessageBuffer 参数。（缺陷号 32797240）

不成功CREATE TABLE的NDB表会返回一般错误消息 ( ERROR HY000: Can't create table ' tbl' )，另外，更具体的错误消息通常作为警告推送。为了帮助可能没有意识到这一点并且只看到一般消息的用户，我们 SHOW WARNINGS在一般错误消息中添加了关于声明的提醒文本，以提示用户获取可能有助于更快解决给定问题的其他信息。（缺陷号 32788231）

未NDB映射到 MySQL 处理程序错误代码的错误通常作为错误 1296 或 1297 呈现给 MySQL 用户，并带有指示底层 NDB错误代码的消息；此行为的一个例外是COMMIT错误（源自 ndbcluster_commit()），通常的 NDB错误是 4350 Transaction already aborted。MySQL 最终在 C 库中将其传递给 strerror()C 库，在 C 库中它以Unknown error或类似的为前缀，但该前缀的精确格式因平台特定差异以及 libc所使用的版本而异。

我们通过创建 与 SQL State 25000 Invalid Transaction StateHA_ERR_TX_FAILED关联的新处理程序错误和新客户端错误 来解决此问题。（缺陷号 32763179）ER_TRANSACTION_FAILED

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

使用该 --print-full-config选项启动时， ndb_mgmd退出时出现错误 Address already in use。指定此选项时，可通过跳过空闲端口验证来解决此问题。（缺陷号 32759903）

删除了在对表执行查询时在集群日志中生成的不需要的打印输出 ndbinfo.cluster_locks。（缺陷号 32747486）

当使用 MySQL 客户端库的线程完成此操作时，DbUtil该类没有调用mysql_library_end()，也没有通过调用释放线程的本地资源 mysql_thread_end()。（缺陷号 32730214）

使用同一个实例DbUtil第二次运行查询时 发生内存泄漏 ；DbUtil连接检查没有检测到现有的MYSQL实例，没有释放就替换掉了。（缺陷号 32730047）

在确定表使用的分区数时返回错误NDB导致 MySQL 服务器将.frm 文件中的不正确信息 table写入其错误日志，尽管指示的文件不存在。NDB当用户试图在 MySQL 服务器实际未连接到 .时打开表时，这也会导致错误日志泛滥的问题NDB。

我们通过更改确定分区数的函数来解决此问题，以使用从 MySQL 数据字典加载的值而不是从中获取它NDB，这也节省了打开表时的一次往返。对于打开表进行升级的特殊情况，我们回退到从NDB升级代码路径中获取值。（漏洞#32713166）

将重复的节点 ID 与CREATE NODEGROUP（例如，CREATE NODEGROUP 11, 11）一起使用可能会导致集群意外关闭。现在，当此命令包含重复的节点 ID 时，它会引发错误。（缺陷号 32701583）

改进了对 ndbinfo.cluster_locks表的查询性能，该表在某些情况下可能运行得很慢。（缺陷号 32655988）

修复了在 ndb_print_backup_file中发现的一些与参数解析、错误报告和使用来自ndbxfrm的类打开加密文件有关的问题。（缺陷号 32583227）

该目录unittest/ndb是由构建过程生成的，即使它没有被使用。构建时不再创建此目录NDB。（缺陷号 32553339）

为确保在主存中为重做日志保留的日志记录在一秒内写入重做日志文件，时间管理器在DBLQH写入之前获取重做日志部分的锁。先前问题的修复导致重做日志文件尚未打开并准备好写入时发送 continueB 信号（作为该修复的一部分引入），然后返回而不释放锁定。在这种情况下，我们会在等待重做日志文件打开并准备写入之前释放获取的锁。（缺陷号 32539348）

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

在每个纪元开始时和处理一个事件后，更新用于从二进制日志注入器线程中 Ndb接收事件的对象的值，当每个纪元更新一次值就足够时。 NDBndb_eventbuffer_max_alloc

我们通过在处理每个事件期间不从全局值更新来解决此问题，这减少了每个事件处理循环期间所需的工作量。（缺陷号 32494904）

从事件流中读取时未能找到 blob 列的所有 blob 部分未得到正确处理，这导致调用者的复制缓冲区中的数据不完整，没有错误返回给调用者。

当通知事件 API 的用户已收到包含 blob 列的表的数据时，它会创建一个足够大的缓冲区来容纳整个 blob，然后调用函数从事件流中读取 blob 列。大多数 blob 类型都存储为几个小部分NDB；要从事件流中读取 blob 列的 blob 数据，必须遍历缓冲的事件数据以找到 blob 部分并将每个部分复制到提供的缓冲区中。检查与 blob 列关联的每条缓冲事件数据，以查看它是否包含所需 blob 部分的数据。当找到一个 blob 部分时，它被复制到缓冲区中由调用者提供的原始偏移量。

查找 blob 部分的函数可以一次复制一个或多个 blob 部分。在将 blob 部分放在一起时，通常会多次调用此函数 - 首先找到第一个 blob 部分，然后是中间的所有部分（一次几个），然后是最后一部分的其余部分。当函数在缓冲的事件数据中找不到所有请求的 blob 部分时，这会导致不一致，这可能由于几种不同情况中的任何一种而发生——所有部分可能尚未发送，接收到的部分可能已存储在错误的地方，将 blob 部分放在一起的逻辑有问题，或者可能是其他问题。

在调查执行某些操作时可能发生的计划外 SQL 节点关闭问题时注意到了这个问题ALTER TABLE，其中调试编译的mysqld在打印了有关丢失的 blob 部分的信息后断言；手动代码检查表明，发布编译的二进制文件只会将不完整的缓冲区返回给调用者。在解决以前的一些类似问题时也注意到了这个问题。

NdbEventOperationImpl::readBlobParts() 我们通过在找不到请求的 blob 部分时 返回错误来解决此问题 。由于这是一个严重的不一致，我们还扩展了检测到此问题时提供的打印输出。此处显示了扩展打印输出的示例：

= print_blob_part_bufs =============================
part_start: 0, part_count: 15
table: { id: 13, version: 2, name: 't1' }
column: { attrid: 1, name: 'b' }
blob parts table: { id: 14, version: 2, name: 'NDB$BLOB_13_1' }
available buffers: {
[0]*:  part_number: 1, size: 2000, offset: 2000
[1]*:  part_number: 14, size: 2000, offset: 28000
[2]*:  part_number: 7, size: 2000, offset: 14000
[3]*:  part_number: 5, size: 2000, offset: 10000
[4]*:  part_number: 3, size: 2000, offset: 6000
[5]*:  part_number: 0, size: 2000, offset: 0
[6] :  part_number: 15, size: 2000, offset: 30000
[7]*:  part_number: 13, size: 2000, offset: 26000
[8]*:  part_number: 12, size: 2000, offset: 24000
[9]*:  part_number: 11, size: 2000, offset: 22000
[10]*:  part_number: 10, size: 2000, offset: 20000
[11]*:  part_number: 9, size: 2000, offset: 18000
[12]*:  part_number: 8, size: 2000, offset: 16000
[13]*:  part_number: 6, size: 2000, offset: 12000
[14]*:  part_number: 4, size: 2000, offset: 8000
[15]*:  part_number: 2, size: 2000, offset: 4000
}

（缺陷号 32469090）

参考资料：另请参阅：Bug #32405937、Bug #3050​​9284。

在重启期间允许节点在完成恢复之前参与备份，而不是让其等待恢复完成。（缺陷号 32381165）

NDB_WIN32从 NDB Cluster 源中 删除。此定义曾经旨在将代码划分为仅针对 Windows 进行条件编译，但长期以来已被_WIN32. （缺陷号 32380725）

执行 NDB备份时磁盘空间不足可能会导致集群意外关闭。（缺陷号 32367250）

索引统计线程依赖于二进制日志注入器线程来通知它有关初始系统重启的信息。索引统计线程然后（异步地）回收它的 Ndb对象并创建它的系统表。根据时间安排，索引统计线程可能在NDB 表可写的一段时间内未准备好为请求提供服务。IndexStatAutoCreate当数据节点参数设置为 1 时，这也会导致在设置存储授权期间出现问题 。

我们通过两种方式解决这个问题：

（缺陷号 32355045）

可以在 设置为 1 且文件中定义超过 72 个数据节点的 情况下启动ndb_mgmd。现在管理服务器检查这种情况，如果发现则拒绝启动。（缺陷号 32258207）NoOfReplicasconfig.ini

可以使用为 参数设置的无效值 启动ndb_mgmd；随后，使用该值的数据节点进程无法启动。现在在这种情况下，管理服务器拒绝启动，并提供适当的错误消息。（缺陷号 32210176）config.iniNodeGroup

ALTER TABLE t1 ALGORITHM=INPLACE, RENAME COLUMN B to b执行列的就地重命名的 语句 仅更改其名称的字母大小写是成功的，但更改未反映在NDB字典中（例如，如ndb_desc的输出所示）。我们通过确保NDB字典始终匹配 SQL 语句中指定的字母大小写来解决此问题，并且这与存储在 MySQL 数据字典中的名称匹配。（缺陷号 31958327）

事件缓冲区拥塞可能导致执行二进制日志记录的 SQL 节点意外关闭。我们通过更新二进制日志记录处理程序来解决此问题，以使用 Ndb::pollEvents2()（而不是弃用的pollEvents() 方法）来正确捕获和处理此类错误。（缺陷号 31926584）

除非还指定了选项，否则ndb_import 的--resume选项 无法正常工作 。（缺陷号 31107058）--stats

恢复了以前对标志范围的更改 INSERT IGNORE以及其他类似的 SQL 语句，以通知处理程序插入或更新期间的重复键错误不会停止正在进行的事务。现在，这些标志在每次写入行事件后都会被清除，就像以前一样。（漏洞#27538524）

参考资料：另请参阅：Bug #22603412。此问题是 Bug #20017428 的回归。

NDBCLUSTER使用 type 的位图 MY_BITMAP来跟踪在各种上下文中要使用哪些列。当在短期的性能关键代码中使用时，它们使用一个位缓冲区进行初始化，其（固定）大小在编译时定义。这些缓冲区的大小是通过多种方式计算的，这可能导致复制粘贴错误、缓冲区是否足够大的不确定性以及可能分配的多余空间。

我们通过实现一个内部 Ndb_bitmap_buf类来解决这个问题，该类将缓冲区应包含的位数作为模板参数，并将所有出现的静态位图缓冲区更改为 Ndb_bitmap_buf. 这还在缓冲区太大的条件下推代码中节省了几个字节。（漏洞 #27150799）

DELETE其 WHERE子句引用 列 的语句BLOB未正确执行。（漏洞 #13881465）

数据节点和管理节点日志的分析有时会受到阻碍，因为并非所有日志消息都包含时间戳。这是通过用现有机制替换许多不同的日志记录函数（printf、 fprintf、ndbout、 ndbout_c、<< 重载等）并对其进行标准化来解决的，该 机制以格式 EventLogger的时间戳开始每条日志消息。YYYY-MM-DD HH:MM:SS

有关 NDB Cluster 事件日志和日志消息格式的更多信息，请参阅 NDB Cluster 中生成的事件报告。

参考资料：另请参阅：Bug #21441915、Bug #30455830。