为了防止未经授权从备份恢复数据，此版本增加了对NDB 使用 AES-256-CBC 的本机加密备份的支持。加密的备份文件受用户提供的密码保护。 NDB不保存此密码；这需要由用户或应用程序完成。要创建加密备份，请使用ndb_mgm 客户端 命令（除了可能需要的任何其他选项之外）。 您还可以通过调用 MGM API函数 在应用程序中启动加密备份。ENCRYPT PASSWORD=passwordSTART BACKUPndb_mgm_start_backup4()

要从加密备份中恢复， 请将 ndb_restore与选项 --decrypt和 一起使用。 ndb_print_backup_file还可以使用此版本中添加的选项 读取加密文件。--backup-password=password-P

!与此功能一起使用的加密密码可以是除, ', ", $, %, \, 和 之外的可打印 ASCII 字符范围内最多 256 个字符的任何字符串^。当提供用于加密或解密的密码时，必须使用单引号或双引号将其引起来。可以使用''或 指定一个空密码，""但不推荐这样做。

您可以使用ndbxfrm实用程序 加密现有备份文件，该 实用程序已添加到此版本中的 NDB Cluster 分发版中；该程序还可以解密加密的备份文件。ndbxfrm还压缩和解压缩 NDB Cluster 备份文件。CompressedBackup压缩方法与启用 时 NDB Cluster 用于创建压缩备份的方法相同 。

也可以要求使用 RequireEncryptedBackup. 当启用此参数（通过将其设置为 1）时，管理客户端拒绝任何执行未加密备份的尝试。

有关更多信息，请参阅 使用 NDB Cluster 管理客户端创建备份，以及ndbxfrm — 压缩、解压缩、加密和解密 NDB Cluster 创建的文件。

NDB 客户端程序：自此 版本开始，MySQL NDB Cluster 自动安装程序 ( ndb_setup.py ) 已被弃用，并且在 NDB Cluster 的未来版本中将被删除。（缺陷号 31888835）

重要更改： 状态Ndb_metadata_blacklist_size变量已重命名为 Ndb_metadata_excluded_count. （缺陷号 31465469）

打包：server-minimal对 NDB Cluster 的 RPM 和 NDB Cluster Docker 映像进行 了以下改进

（缺陷号 31838832）

添加了 CMake 选项 NDB_UTILS_LINK_DYNAMIC，以允许 NDB 实用程序与 ndbclient. （缺陷号 31668306）

现在支持 IPv6 寻址连接到管理节点和数据节点，包括管理节点和数据节点与 SQL 节点之间的连接。要使 IPv6 寻址正常工作，集群部署的运行平台和网络必须支持 IPv6。主机名解析到 IPv6 地址必须由操作平台提供（这与使用 IPv4 寻址时相同）。

不建议在同一集群中混合使用 IPv4 和 IPv6 地址，但这可以在以下任一情况下工作，前提 --bind-address是不与 ndb_mgmd一起使用：

从不支持 IPv6 寻址的 NDB 版本升级到支持 IPv6 寻址的版本时，网络必须已经支持 IPv4 和 IPv6。必须先进行软件升级；此后，您可以使用config.ini 所需的 IPv6 地址更新配置文件中使用的 IPv4 地址。最后，为了使配置更改生效，请执行集群的系统重启。

重要变更；NDB Cluster API： 用于 Node.js 的 NDB Cluster 适配器是针对运行时的过时版本构建的。现在它是使用 Node.js 12.18.3 构建的，并且仅支持该版本或更高版本的NDBNode.js。（缺陷号 31783049）

重要更改： 为了同步排除的元数据对象，有必要更正潜在问题（如果有），然后再次触发对象的同步。这可以通过发现单个表来实现，这不会随着表和 SQL 节点数量的增加而很好地扩展。也可以通过将 SQL 节点重新连接到集群来完成，但这样做也会产生额外的开销。

ndb_metadata_sync为解决此问题，在用户启用 时清除因同步失败而排除的数据库对象列表 。这使得所有此类对象都符合在后续检测运行中进行同步的条件，从而简化了对所有已排除对象的同步重试。

此修复程序还删除了对要重试的对象的验证，该验证以前在每次检测运行开始时进行。由于这些对象仅在 ndb_metadata_sync启用时才有意义，因此当禁用此变量时要重试的对象列表将被清除，这表明所有更改都已同步。（缺陷号 31569436）

打包： NDB Cluster 附带的 Dojo 库已升级到 1.15.4 版本。（缺陷号 31559518）

NDB 磁盘数据： ndbmtd有时在还原操作期间无法完成对日志文件组的查找时意外终止。（缺陷号 31284086）

NDB 磁盘数据： 在创建足够的磁盘数据对象以填充表空间后升级具有 3 或 4 个副本的集群时，以及在磁盘数据表上执行插入时，尝试停止某些数据节点导致其他数据节点不正确退出。（缺陷号 30922322）

NDB Cluster API： 在某些情况下，该 Table::getColumn()方法返回了错误的Column 对象。当一个表列的全名是另一个表列名称的前缀时，或者当两个列的名称具有相同的散列值时，就会发生这种情况。（缺陷号 31774685）

NDB Cluster API： 可以使用 blob 生成无效的 NDB API 方法调用序列。这是因为某些方法调用隐式导致事务执行内联，以处理 blob 部分和其他问题，这可能导致用户定义的操作无法正确处理，因为使用执行与 blob 相关的操作的方法仍然存在用户 -定义的 blob 操作挂起。现在在这种情况下，NDB 会引发一个新错误 4558 Pending blob operations must be executed before this call。（漏洞#27772916）

ndb_restore --remap-column没有NULL正确处理包含值的列。现在，与此选项一起使用的映射函数指定的任何偏移量都不会应用于NULL，因此NULL会按预期保留。（缺陷号 31966676）

ndb_print_backup_file实用程序不遵守行数据的字节顺序。该工具现在对行页面信息执行字节交换，以确保在大端和小端平台上获得相同的结果。（缺陷号 31831438）

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

在某些情况下，从 8.0.18 之前的 NDB Cluster 版本升级到更高版本后，写入 sysfile（请参阅 NDB Cluster 数据节点文件系统目录）并从中读取无法正常工作。当已对数据节点进行显式节点组分配（使用NodeGroup 参数）时，可能会发生这种情况；节点组分配可能会自发更改，甚至可能添加配置文件中未引用的节点组。这是由于sysfileNDB 8.0.18 中引入的格式版本 2 存在问题。（漏洞 #31828452，漏洞 #31820201）

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

在遇到配置文件中使用的数据节点后NodeGroup=65536，管理服务器停止将缺少明确NodeGroup设置的数据节点分配给节点组。（缺陷号 31825181）

在某些情况下，数据节点在PGMAN内核块中经历了致命的内存损坏，这是由于页面对齐 32KB 的无效假设，而实际上它们通常与系统页面大小（4096 或 8192 字节，取决于平台）对齐。（错误#31768450，错误#31773234）

修复了 NDB 8.0.20 中引入的拼写错误的定义，该定义使用于控制自适应旋转的内部函数无法运行。（缺陷号 31765660）

在撤消日志恢复期间执行撤消日志记录时，可能会在命中页面缓存未命中时多次使用先前的撤消日志记录。（缺陷号 31750627）

如果在模式分发期间发生 SQL 节点或集群关闭，而协调器仍在等待参与者，则模式分发会中途中止，但ndb_schema_result与此模式操作相关的任何行都不会被清除。如果具有相同模式操作 ID 的 DDL 操作源自使用相同节点 ID 的客户端，则这些行可能会与参与者未来的回复发生冲突。

为了防止这种情况发生，我们现在 在二进制日志设置ndb_schema_result期间 清除所有此类行。NDB这确保没有正在进行的 DDL 分配，并且ndb_schema_result表中剩余的任何行都已经过时。（缺陷号 31601674）

MySQL Cluster Auto-Installer 的帮助输出显示了错误的版本信息。（缺陷号 31589404）

在某些极少数情况下，NDB错过检查本地检查点的完成情况，使其未完成，这意味着后续的本地检查点无法执行。（缺陷号 31577633）

数据定义语句有时可能涉及从表中读取或写入多行（或两者）； NDBCLUSTER开始 NdbTransaction执行这些操作。当这样的语句被回滚时， 试图在回滚 和关闭它NDBCLUSTER之前回滚模式更改；这导致回滚无限期挂起，而集群在能够回滚模式更改之前 NdbTransaction等待 对象关闭。NdbTransaction

现在在这种情况下，NDBCLUSTER仅在回滚并关闭Transaction与更改关联的任何打开的 Ndb 之后才回滚模式更改。（缺陷号 31546868）

NDB_STORED_USER当权限被授予新用户 时，添加新用户并不总是正确同步到所有 SQL 节点 。（缺陷号 31486931）

在某些情况下，QMGR返回冲突的NDB引擎和 MySQL 服务器版本信息，这可能导致管理节点意外关闭。（缺陷号 31471959）

SUMA正在启动的节点上的节点不应向主节点上DICT_UNLOCK_ORD 的块发送信号，DICT直到所有 SUMA_HANDOVER_REQ发送的信号都已发送 SUMA_HANDOVER_CONF信号作为响应，并且在接收到时设置的每个切换桶 SUMA_HANDOVER_CONF已完成切换。在某些极少数情况下使用 NoOfReplicas> 2，并且全局检查点之间的延迟异常短，一些切换桶可能比其他桶更早准备好进行切换，并且即使在这种情况下也可以继续进行切换。（缺陷号 31459930）

NDB从使用索引或列顺序与表不同的主键的表中 读取数据时，需要进行属性ID映射。对于唯一索引，在打开表时创建一个缓存的属性 ID 映射，然后用于每次后续读取，但对于主键读取，映射是为每次读取构建的。这已更改，以便在打开表时构建和缓存主键的属性 ID 映射，并在任何后续读取需要时使用。（缺陷号 31452597）

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

在恢复过程的不同阶段， ndb_restore对临时错误使用不同的重试次数以及重试之间的不同休眠时间。这是通过在所有恢复阶段实施一致的重试计数和休眠时间来解决的。（缺陷号 31372923）

删除 NDBCLUSTER了使用 Clang 10 编译时生成的警告。（缺陷号 31344788）

该SPJ块包含生成 LQHKEYREQ信号时使用的负载节流机制。当这些是从一次扫描的父行生成的，并且该扫描有一个复杂的拓扑结构，其中有多个子节点执行键查找时，可能会因信号过多而使作业队列过载 LQHKEYREQ，从而导致节点因作业缓冲区已满而关闭。此问题最初由错误 #14709490 修复。对该问题的进一步调查表明， 即使查询不忙，也可能发生作业缓冲区已满错误。SPJ由于内部批量大小的增加SPJ NDB 7.6.4 中的工作人员作为在向块发送SCAN_FRAGREQ 信号时实现使用多个片段的工作的一部分，SPJ当并行运行相对少量的此类查询时，即使是简单的查询也可能会填满作业缓冲区。

LQHKEYREQ为了解决这个问题，一旦给定请求中未完成的信号数量超过 256 ，我们就不再发送任何进一步 的信号。相反，LQHKEYREQ缓冲生成 的父行，并将该行的相关 ID 存储在集合中的操作将在稍后恢复。（缺陷号 31343524）

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

MaxDiskWriteSpeedOwnRestart 在节点重启期间不被视为本地检查点写入的上限。（缺陷号 31337487）

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

在某些罕见的情况下，DROP TABLE表的NDB触发断言。（缺陷号 31336431）

在节点重启期间 SUMA，正在启动的节点的块必须从已经运行的节点获取订阅（带有订阅者的事件）和订阅者（NdbEventOperation​​正在执行的实例）的副本。在复制完成之前，仍在启动的节点将忽略任何用户级别SUB_START或 SUB_STOP请求；复制完成后，他们可以参与此类请求。当复制操作正在进行时，用户级别SUB_START和 SUB_STOP请求被 DICT锁阻塞。

发现一个问题，即在请求锁定之后但在授予之前， 起始节点可以参与 SUB_START和请求，从而导致不成功和 请求。此修复可确保节点在 实际授予锁定之前无法参与这些请求。（缺陷号 31302657）SUB_STOPSUB_STARTSUB_STOPDICT

当文件系统运行并且数据文件写入未与写入使用的 512 字节块大小对齐时， 备份因 FsErrInvalidParameters出错。如果数据文件中的总片段大小与 块大小不对齐， 则将最后一次写入填充到所需大小，但是当没有片段可写时， 仅将页眉和页脚写入数据文件。由于页眉和页脚小于 512 字节，导致写入出现问题。 O_DIRECTO_DIRECTO_DIRECTNDBBACKUPO_DIRECT

EMPTY_ENTRY如果需要，可以通过在关闭数据文件时 使用 , 将通用页脚填充到 512 字节来解决此问题。（缺陷号 31180508）

当采用需要缓冲接收到的关键行供以后使用的执行策略时， DBSPJ现在逐个树节点管理缓冲内存分配树节点，导致DBSPJ 块的 CPU 使用率显着下降。（缺陷号 31174015）

DBSPJ现在使用线性内存代替分段内存来存储和处理 TRANSID_AI信号，这比以前消耗的 CPU 节省了大约 10%。由于这一变化，现在可以DBSPJ接受 TRANSID_AI短信号格式的信号；这比需要分段存储器的长信号格式更有效。（错误#31173582，错误#31173766）

ALGORITHM=INPLACE使用导致断言 更改完全复制表的表注释 。（缺陷号 31139313）

本地数据管理器 (LDM) 具有一种机制，可确保片段扫描在发现行太少而无法在合理的时间内填充可用的批处理大小时（例如当 ScanFilter 对大多数情况下的计算结果为 false 时）不会无限期地继续扫描的行）。当此时间限制（设置 DBLQH为 10 毫秒）到期时，将返回到该时间点为止找到的所有行，而与指定的批处理大小是否已填充无关。这充当数据和 API 节点之间的保持活动机制，并避免在扫描期间保持任何锁持有时间过长。

这样做的一个副作用是，将结果行批次返回到DBSPJ填充量远低于预期限制的块可能会导致性能问题。这不仅是因为为批处理保留的空间利用率低，需要更多的NEXTREQ 往返，而且还因为它还导致DBSPJ 内部并行统计变得不可靠。

由于DBSPJ块在执行扫描时从不请求锁，因此过长的锁对于 SPJ 请求不是问题。因此，让请求的扫描DBSPJ持续时间超过之前允许的 10 毫秒被认为是安全的，并且设置的限制 DBLQH已增加到 100 毫秒。（缺陷号 31124065）

对于推送连接，来自的输出 EXPLAIN FORMAT=TREE未指示表访问是返回多行的索引范围扫描，还是对主键或唯一键的单行查找。

此修复程序还提供了一个较小的优化，这样如果已知访问类型为 ，则不会多次访问处理程序接口以尝试返回多行Unique。（缺陷号 31123930）

先前的更改（在 NDB 8.0.20 中进行）使得在表上进行推送连接成为可能，允许READ_BACKUP将两个 SPJ worker 放置在DBTC块本地的数据节点上，同时在其他节点上不放置任何 SPJ worker；这种有时的不平衡是有意为之的，因为 SPJ 工作负载（以及可能引入的不平衡）通常与启用备份片段的更多本地读取的收益相比非常低。作为相同更改的意外副作用，这两个位于同一地点的 SPJ 工作人员可能会并行扫描相同的片段子集；这打破了一个假设 DBSPJ阻止在每个数据节点上只实例化一个 SPJ worker，确保每个 SPJ worker 从不同的片段开始扫描的逻辑依赖于该逻辑。

为了解决这个问题，每个 SPJ worker 的起始片段现在是根据 worker 开始的根片段 ID 计算的，这在所有 SPJ worker 中都是唯一的，即使它们中的一些驻留在同一个节点上也是如此。（缺陷号 31113005）

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

将集群从 NDB 8.0.17 或更早版本升级到 8.0.18 或更高版本时，在将管理服务器（或多个管理服务器）升级到新软件版本后，尚未升级的数据节点可能会意外关闭。当管理客户端STOP 命令被发送到一个或多个仍在运行旧版本的数据节点并且新的主节点（也运行旧版本的NDB软件）随后经历了计划外关闭时，就会发生这种情况。

发现这是由于在发送一个信号长度和信号部分的数量时错误地设置了信号部分 GSN_STOP_REQ的数量——在 NDB 8.0 中，作为支持更多数据节点的工作的一部分，其长度已经增加的信号之一——到新主人。发生这种情况是由于使用了将 a 发送GSN_STOP_REQ到先前主节点时保留的陈旧数据。为了防止这种情况发生， ndb_mgmd现在每次在发送 GSN_STOP_REQ信号之前都明确设置信号长度和部分数量。（漏洞#31019990）

在某些情况下，当重放日志和恢复元组时发生故障时，ndb_restore终止而不是返回错误。此外，某些操作的重试次数由硬编码值决定。（缺陷号 30928114）

在模式分发期间，如果客户端在 DDL 操作已经记录在 ndb_schema表中之后被终止，但在参与者可以回复之前，客户端只是将所有参与者标记为失败NDB_SCHEMA_OBJECT并返回。由于分发协议已经在进行中，协调器继续等待参与者，接收他们的ndb_schema_result插入并处理它们；同时，客户端打开发送另一个 DDL 操作；如果在协调器完成处理之前的模式更改之前执行了一个并开始了它的分发，这将触发一个断言，在任何给定时间应该只有一个模式操作的分发处于活动状态。

此外，当客户端返回时检测到线程被杀死，它也会释放全局模式锁（GSL）；这也可能导致未定义的问题，因为参与者可以在 GSL 仍由协调员持有的假设下进行更改。

在这种情况下，客户端不应在 DDL 操作记录到ndb_schema 表中后返回；从这一点来看，协调者拥有控制权，客户应该等待它做出决定。现在，协调器仅在服务器或集群关闭的情况下中止分发，否则等待所有参与者回复，或超时并将模式操作标记为已完成。（缺陷号 30684839）

GCP_SAVEREQ当在重启期间，数据节点在开始阶段 9 之前 收到 信号，因此需要执行全局检查点索引写入本地数据管理器的本地检查点控制文件，它没有记录来自DIH块的信息发送信号作为写入数据的一部分的节点。这意味着，稍后在启动阶段 9 中，当尝试发送 GCP_SAVECONF信号以响应 时 GCP_SAVEREQ，此信息不可用，这意味着无法发送响应，从而导致数据节点意外关闭。（缺陷号 30187949）

设置 EnableRedoControl为 false没有完全禁用 MaxDiskWriteSpeed、 MaxDiskWriteSpeedOtherNodeRestart和 MaxDiskWriteSpeedOwnRestart 预期的那样。（漏洞#29943227）

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

一个BLOB值存储 NDB在多个部分中；读取这样的值时，每个部分执行一次读取操作。如果未找到某个部分，则读取失败并显示行未找到错误，这表示已损坏 BLOB，因为 aBLOB不应有任何丢失的部分。可能会出现问题，因为此错误被报告为读取操作的总体结果，这意味着 mysqld 没有看到错误并报告返回了零行。

通过添加专门针对未找到 blob 部分的情况的检查来解决此问题。现在，当发生这种情况时，用损坏的 blob覆盖行未找到错误 ，这会导致原始语句按预期失败。NDB API 的用户应该知道，尽管有此更改，该 方法仍会继续报告错误，因为在这种情况下找不到行。（缺陷号 28590428）SELECTNdbBlob::getValue()

配置参数为1时数据节点没有启动， RealtimeScheduler 这是因为启动时的索引构建是通过临时挪用一些I/O线程作为索引构建线程，这些线程继承了实时性的特性I/O线程。当检查索引构建线程规范以确保它们不是实时线程时，这会导致冲突（被视为致命错误）。这是通过确保索引构建线程不被视为实时线程来解决的，无论任何设置应用于它们的主机 I/O 线程，这是它们设计中的实际意图。（漏洞#27533538）

使用就地ALTER TABLE删除索引可能会导致 SQL 节点意外关闭。（漏洞#24444899）

ALTER TABLE ... ALGORITHM=INPLACE作为执行时 的最后一步 ，NDBCLUSTER从字典中读取表元数据NDB，需要在 SQL 节点和数据节点之间进行额外的往返，这既不必要地减慢了语句的执行速度，又 NDBCLUSTER为未准备好的错误提供了途径正确处理。NDB通过在执行就地ALTER TABLE语句的最后阶段删除表元数据的读取来解决此问题 。（缺陷 #99898，缺陷 #31497026）

NDB为就地 准备表时可能会发生内存泄漏 ALTER TABLE。（缺陷 #99739，缺陷 #31419144）

添加了 AllowUnresolvedHostNames 配置参数。当设置为 时，此参数会覆盖通常在ndb_mgmd无法连接到给定主机名true时引发的致命错误 ，从而允许启动继续并仅生成警告。要生效，必须在集群全局配置文件的部分中设置该参数。 [tcp default]