重要变更；NDB 复制：replica_allow_batching 系统变量会影响副本应用纪元事务的效率 。当设置为OFF时，默认情况下，二进制日志中的每个离散复制事件都会单独应用和执行，这通常会导致性能不佳。

从此版本开始，默认值 replica_allow_batching从更改 OFF为ON。

NDB Replication： NDB Cluster Replication 支持在循环复制设置中使用的冲突检测和解决，以确定当它使用与另一个操作相同的主键时是否应用给定的操作。以前，可以解决更新和删除操作的主键冲突，但对于具有相同主键的写操作，唯一执行的处理是拒绝任何与现有主键相同的写操作，并仅应用如果不存在具有相同主键的写操作。

此版本引入了两个新的冲突解决函数 NDB$MAX_INS() 和 NDB$MAX_DEL_WIN_INS(). 这些函数中的每一个都按照此处显示的步骤处理插入（写入）操作之间的主键冲突：

NDB$MAX_INS()以与 相同的方式处理冲突的更新和删除操作 NDB$MAX()，并且 NDB$MAX_DEL_WIN_INS()以与 相同的方式进行处理NDB$MAX_DELETE_WIN()。

此增强功能支持在处理冲突的复制写入操作时配置冲突检测，以便INSERT幂等地应用具有较高时间戳列值的复制，并INSERT拒绝具有较低时间戳列值的复制。

与其他冲突解决功能一样，可以选择将被拒绝的操作记录在异常表中，并且被拒绝的操作会增加一个计数器；对于“更大的时间戳获胜”处理，这是状态变量 Ndb_conflict_fn_max_ins，对于“相同的时间戳获胜”策略，递增的计数器是 Ndb_conflict_fn_max_del_win_ins。

有关详细信息，请参阅 冲突解决函数。（缺陷号 33398980）

NDB 复制： 以前，写入副本 NDB Cluster 时 --ndb-batch-size使用的批大小由 控制，用于将 blob 数据写入副本的批大小由 确定 ndb-blob-write-batch-bytes。由于副本使用了这些变量的全局值，该方案导致了问题；这意味着在副本上更改其中一个或两个也会影响所有其他会话使用的值。这种安排的另一个缺点是不可能为副本应用程序独有的这些选项设置不同的默认值，它最好具有比其他会话更高的默认值。

此版本通过添加两个特定于副本应用程序的新系统变量解决了这些问题。 ndb_replica_batch_size现在控制用于副本应用程序的批量大小， ndb_replica_blob_write_batch_bytes 变量现在确定用于在副本上执行批量写入 blob 的 blob 写入批量大小。

此更改应使用默认设置改进 MySQL NDB Cluster Replication 的行为，并允许用户微调 NDB 复制而不影响用户线程执行其他任务，例如处理 SQL 查询。

有关详细信息，请参阅新系统变量的说明。另请参阅 准备 NDB Cluster 进行复制。

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

NDB Cluster API：通过 使用 std::uniqe_ptr管理 . EventDictionary::getEvent()

作为此修复的一部分，我们添加了一种 releaseEvent() 方法Dictionary来清理getEvent()不再需要的事件。（缺陷号 33855045）

NDB Cluster API： NDB Cluster 包含 的Node.JS包已更新到版本 16.5.0。（缺陷号 33770627）

CSV 文件中的空行现在被 ndb_import接受为有效输入。（以前，此类文件中的空行总是被拒绝。）现在，如果一个空值可以用作单个导入列的值， ndb_import将以与 LOAD DATA. （缺陷号 34119833）

NDB以不同于其他类型的方式存储 blob 列值；默认情况下，只有值的前 256 个字节存储在表中（“内联”），其余部分保存在单独的 blob 部分表中。这适用于 MySQL 类型 BLOB、 MEDIUMBLOB、LONGBLOB、 TEXT、 MEDIUMTEXT和的列LONGTEXT。（TINYBLOB并且TINYTEXT是例外，因为它们始终仅内联。） 以类似的方式NDB处理 JSON列值，唯一的区别是，对于 JSON列，值的前 4000 个字节是内联存储的。

NDB以前，只能通过使用 NDB API（Column::setInlineSize() 方法） 来控制表的 blob 列的内联大小。这现在可以在mysql 客户端（或其他提供 SQL 接口的应用程序）中使用列注释 来完成，该列注释由NDB_COLUMN包含规范的字符串 组成BLOB_INLINE_SIZE，作为如下 CREATE TABLE语句的一部分：

CREATE TABLE t (
    a BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    b BLOB COMMENT 'NDB_COLUMN=BLOB_INLINE_SIZE=3000'
) ENGINE NDBCLUSTER;

在t刚才的语句创建的表中，column b（上例中强调的文本）是一BLOB列，其前3000字节存储在t自身中，而不仅仅是前256字节。这意味着，如果存储的值没有超过 3000 字节的长度，则在存储或检索列值时b不需要额外的工作来从 blob 部分表读取或写入任何多余的数据。NDB在对 blob 列执行许多操作时，这可以显着提高性能。

ndbinfo.blobs您可以通过查询表或检查ndb_desc的输出 来查看此选项的效果 。

支持的最大值为 BLOB_INLINE_SIZE29980。将其设置为任何小于 1 的值都会导致对列使用默认的内联大小。

您还可以在复制过程中更改列 ALTER TABLE； ALGORITHM=INPLACE不支持此类操作。

BLOB_INLINE_SIZE可以单独使用，也可以MAX_BLOB_PART_SIZE在同一个 NDB_COMMENT字符串中一起使用。与 的情况不同 ，表的列支持 MAX_BLOB_PART_SIZE设置 。 BLOB_INLINE_SIZEJSONNDB

有关详细信息，请参阅 NDB_COLUMN 选项以及字符串类型存储要求。（缺陷号 33755627）

向ndb_import添加了 一个新--missing-ai-column 选项。这使 ndb_import能够接受一个缺少列数据的 CSV 文件，并像以前一样自行提供这些值 。这可以通过 CSV 表示不包含此类列的值的一个或多个表来完成。 AUTO_INCREMENTLOAD DATA

AUTO_INCREMENT仅当 CSV 文件不包含要导入 的列的非空值时，此选项才有效。（缺陷 #102730，缺陷 #32553029）

此版本为 所使用的事务批处理内存添加了 Performance Schema 工具NDBCLUSTER，从而可以监视事务使用的内存。有关详细信息，请参阅 事务内存使用情况。

重要变化： 当使用 ThreadConfig 多线程数据节点参数指定要在数据节点上创建的线程时，recv在某些情况下，接收线程 ( ) 与块线程（例如 DBLQH(0)和DBTC(0)。这代表了 NDB 8.0.22 及更早版本的回归，其中接收线程仅与THRMAN 和 并TRPMAN，正如在这种情况下所预期的那样。

现在，在设置 的值时ThreadConfig，您必须明确地包括main、 rep、recv和 ；ldm为避免使用、 或 线程类型中的一种或多种main，​​您必须 为每种适用的线程类型进行显式设置。 repldmcount=0

1此外，现在对recv计数强制执行 最小值；将复制线程 ( rep) 计数 1设置为也需要 count=1为主线程进行设置。

这些更改可能会对从以前的 NDB Cluster 版本升级产生严重影响。有关详细信息，请参阅 升级和降级 NDB Cluster以及 ThreadConfig MySQL 手册中的参数说明。（缺陷号 33869715）

参考资料：另请参阅：Bug #34038016、Bug #34025532。

macOS： ndb_import无法在 MacOS/ARM 上编译，因为该ndbgeneral库未明确包含在LINK_LIBRARIES. （漏洞#33931512）

NDB 磁盘数据： 内核LGMAN块没有初始化其本地加密文件系统状态，也没有检查 EncryptedFileSystem撤消日志文件，因此它们的加密状态从未真正设置过。

这意味着，对于发布版本，撤消日志文件可能在某些系统上被加密，即使它们不应该被加密；在调试版本中，撤消日志文件始终被加密。这可能会导致在使用磁盘数据表和升级到 NDB 8.0.29 或从 NDB 8.0.29 升级时出现问题。（解决方法是在执行此操作时执行数据节点的初始重启。）

当有大量磁盘数据更新要写入撤消日志时，或者在数据节点启动时读取撤消日志时，此问题还可能导致 I/O 线程出现意外的 CPU 负载。

（缺陷号 34185524）

NDB 复制： 更新NDB源上只有隐藏主键（但没有显式 PK）的表的一行可能会导致副本上的 SQL 线程停止。（缺陷号 33974581）

NDB Cluster API： 内部函数 配置参数的设置时为给定的线程类型 NdbThread_SetThreadPrio()设置线程优先级（在某些情况下，此函数可能在实际成功时返回错误，这可能会对某些 NDB API 应用程序的性能产生不利影响。（缺陷号 34038630）thread_prioThreadConfig

NDB Cluster API：当参数使用非零值时 ，以下 NdbInterpretedCode方法无法正常运行 label：

（缺陷号 33888962）

MySQL NDB ClusterJ： 现在默认启用 ClusterJ 对具有基于 ARM 的 Apple 芯片的系统的支持。（缺陷号 34148474）

由于源代码警告被视为错误，在链接时间优化阶段，Debian 11 和 Ubuntu 22.04 上的 NDB Cluster 编译停止。（漏洞#34252425）

NDB不支持就地更改列的默认值；此类更改只能通过使用复制来进行ALTER TABLE。已经检测到在这种情况下更改默认值，但未检测到添加或删除默认值。

我们通过检测在 期间何时添加或删除默认值ALTER TABLE并拒绝就地执行操作来解决此问题。（漏洞#34224193）

在 SQL 节点 A 上创建用户并授予其 NDB_STORED_USER权限后，从 SQL 节点 B 删除该用户会导致不一致的结果。在某些情况下，drop 没有分发，因此在 drop 之后用户仍然存在于 SQL 节点 A 上。

这个问题的原因是NDB维护了所有本地用户的缓存 NDB_STORED_USER，但是当在 SQL 节点 B 上创建用户时，这个缓存没有更新。后来在执行 的时候DROP USER，这导致SQL节点B判断drop不用分发了。我们通过确保每当创建新的分布式用户时更新此缓存来解决此问题。（缺陷号 34183149）

当在ndbd_exit()数据节点上调用内部函数时，在调用之前发送到事件记录器的信息和错误消息 ndbd_exit()没有按预期打印在日志中。（缺陷号 34148712）

由于 OpenSSL 3.0 的更改，NDB Cluster 在 Ubuntu 22.04 上无法正确编译。（缺陷号 34109171）

由于 Bison fallthrough 处理的变化，NDB Cluster 无法使用 GCC 8.4 正确编译。（缺陷号 34098818）

编译ndbcluster插件或 libndbclient库需要一些文件保存在特定于数据节点 ( src/kernel) 和管理服务器 ( src/mgmsrv) 的目录下。这些现在已被转移到更合适的位置。此处列出了可能感兴趣的已移动文件：

（错误号 34045289）

当在开始模式事务阶段发生错误时，在不释放事务句柄的情况下尝试自动更新索引统计信息，从而导致泄漏。（缺陷号 34007422）

路径长度并不总是由数据节点正确计算。（缺陷号 33993607）

当ndb_restore执行 NDB API 操作并发生任何并发 NDB API 事件时，如果 DBUTIL. 这导致了临时错误NDB。在这种情况下， ndb_restore现在尝试重试失败的 NDB API 操作。（缺陷号 33984717）

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

删除了在内部方法中找到的表指针的重复检查Dbtc::execSCAN_TABREQ()。（缺陷号 33945967）

内部函数 NdbReceiver::unpackRecAttr()从 GSN_TRANSID_AI信号的缓冲区中解压属性值，没有检查以确保属性大小适合缓冲区。这可能会破坏缓冲区，进而导致读取超出缓冲区和复制超出目标缓冲区。（缺陷号 33941167）

改进了日志消息的格式，以便不再绕过某些编译器使用的格式字符串验证。（缺陷号 33930738）

一些NDB内部信号并不总是被正确检查。（缺陷号 33896428）

修复了在使用 GCC 11.2 编译 NDB Cluster 时引发 -Wunused-parameter警告的源代码中的一些问题。（漏洞#33881953）

当 SQL 节点尚未连接到 NDBCLUSTER时，当 SQL 节点无法发现NDB表时，会将过多的警告写入 MySQL 错误日志。（缺陷号 33875273）

NDB API 统计变量 Ndb_api_wait_nanos_count、 Ndb_api_wait_nanos_count_replica和 Ndb_api_wait_nanos_count_session 用于确定应用程序的 CPU 时间和等待时间。这些计数器旨在显示等待数据节点响应所花费的时间，但它们并不完全准确，因为未包括等待关键请求所花费的时间。

有关详细信息，请参阅 NDB API 统计计数器和变量。（缺陷号 33840016）

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

在某些情况下，可能 会在表的 MySQL 数据字典中安装一个重复的条目 engine，即使之前的表定义应该被删除。 se_private_idNDB

当数据节点退出集群需要重新加入时，每个 SQL 节点开始同步自己数据字典中的模式定义。安装在数据字典中的表的 ID 与其se_private_id表 ID相同。使用不同的 ID 更新表是很常见的，例如在执行、 或 语句时。之前的表定义，通过引用中的表获得 NDBNDBALTER TABLEDROP TABLECREATE TABLEschema.table 格式，通常足以进行删除，因此可以使用新 ID 安装新表，因为假定没有其他已安装的表定义使用该 ID。在同步期间可能会发生这种情况的例外情况，如果数据节点关闭允许具有相同 ID 的表的先前表定义而不是要安装的表保留，则旧定义不会被删除。

为了纠正这个问题，我们现在检查要安装在数据字典中的表的 ID 是否与之前的不同，在这种情况下，我们还检查是否已经存在具有该 ID 的旧表定义，如果它确实如此，我们在继续之前删除旧表。（缺陷号 33824058）

收到COPY_FRAGREQ信号后， DBLQH有时会通过将信号对象复制到存储对象中来将信号放入队列中。当此信号对象用于在存储传入信号之前发送另一个信号时，可能会出现问题 COPY_FRAGREQ；这导致保存了一个损坏的信号，该信号在发送时会阻止系统重启完成。我们通过使用信号的静态副本来存储和检索来解决此问题，而不是使用原始信号对象。（漏洞#33581144）

当NDB Cluster 提供的mysqldNDB二进制文件在没有启用支持的情况下运行时，ndbinfo和 ndb_transid_mysql_connection_map插件仍然启用，例如，仍然 ACTIVE在 SHOW PLUGINS. （缺陷号 33473346）

理论上，尝试占用重做日志页可能会由于错误的绑定错误而失败。（缺陷号 32959887）

当使用该 --foreground选项启动数据节点时，并且节点 ID 未配置为从有效主机连接时，数据节点会强制关闭而不是报告错误。（漏洞 #106962，漏洞 #34052740）

NDB表在 MySQL 服务器升级阶段被跳过，而是 ndbcluster在稍后阶段由插件迁移。因此，NDB在从基于 5.7 的版本升级期间，不会创建与表关联的触发器。

NDB发生这种情况是因为当插件迁移表 时无法创建此类触发器ndbcluster，因为有关触发器的元数据在 MySQL 服务器升级的升级完成阶段丢失，其中所有.TRG文件都被删除。

为解决此问题，我们进行了以下更改：

（错误#106883，错误#34058984）

初始化文件时， NDBFS启用自动同步但从未调用do_sync_after_write()（然后调用sync_on_write()），因此文件在保存之前永远不会同步到磁盘。这意味着，对于网络磁盘停滞一段时间的系统，文件可能会用完缓冲文件数据上的系统内存。

do_sync_after_write() 我们通过每次NDBFS写入文件 时 调用来解决这个问题。

作为这项工作的一部分，我们在初始化文件时将自动同步大小从 1 MB 增加到 16 MB。

（错误#106697，错误#33946801，错误#34131456）