对于 Windows，NDB Cluster 的 MSI 安装程序包现在包括对所需 Visual Studio 可再发行包的检查，并在缺少时生成一条消息，要求用户安装它。（缺陷号 30541398）

NDB 磁盘数据： 集群的初始重启现在会导致 字典和 MySQL 数据字典NDB表空间和日志文件组 NDB这包括删除与这些对象关联的所有数据文件和撤消日志文件。（缺陷号 30435378）

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

status 变量 Ndb_metadata_blacklist_size现在已弃用，并在 NDB 8.0.22 中被替换为 Ndb_metadata_excluded_count. （缺陷号 31465469）

当原始数据集都使用相同的模式时，现在可以将来自 NDB Cluster 的不同实例的数据合并到单个目标 NDB Cluster 中。当使用START BACKUP在ndb_mgm中创建的备份并使用ndb_restore恢复它们时，使用 --remap-column此版本中实现的选项（以及 --restore-data可能的其他选项），支持此功能。--remap-column可用于处理源集群之间主要键值、唯一键值或两种键值重叠的情况，您需要确保它们在目标集群中不重叠。也可以这样做以保留表之间的其他关系。

与 一起使用时 --restore-data，新选项将函数应用于指定列的值。为此选项设置的值是格式的字符串 ，其组件列于此处： db.tbl.col:fn:args

您可以--remap-column用于更新同一张表的多列和不同表的不同列，以及多个表和列的组合。同一张表的不同列可以采用不同的偏移值。

作为这项工作的一部分，此版本中还向 ndb_desc添加了两个新选项：

这些选项可能有助于 NDB在计划合并时获取有关表的信息，特别是在mysql 客户端可能不容易使用的情况下。

有关详细信息，请参阅 --remap-column、 --auto-inc和 的说明--context。（缺陷号 30383950）

现在可以从 MySQL Performance Schema 中的表中获取有关自动元数据不匹配检测和同步状态的详细实时信息。此处列出了这两个表：

在这些表中的每一个中，每一行对应一个数据库对象，并包含数据库对象的父模式（如果有）、对象的名称和对象的类型。对象类型包括模式、表空间、日志文件组和表。ndb_sync_excluded_objects除此信息外， 该 表还显示了排除对象的原因。

Performance Schema NDB Cluster Tables提供了有关这些 Performance Schema 表的更多信息。（缺陷号 30107543）

ndb_restore现在使用此版本中引入的选项NDB机备份 还原时支持源表和目标表的不同主键定义--allow-pk-changes支持增加和减少构成原始主键的列数。当需要在恢复数据时适应模式版本更改时，或者这样做比ALTER TABLE在恢复操作后对大量表执行涉及主键更改的语句更有效或更省时时，这可能很有用。

当使用附加列扩展主键时，添加的任何列都不能为空，并且在进行备份时存储在任何此类列中的任何值都不得更改。在尝试将任何此类列添加到表的主键时更改任何此类列的值会导致恢复操作失败。由于某些应用程序在更新行时会设置所有列的值，即使一个或多个列的值没有更改，也可以使用 --ignore-extended-pk-updates 此版本中添加的选项来覆盖此行为. 如果您这样做，必须小心以确保这些列值实际上不会更改。

从表的主键中删除列时，从主键中删除的列之后不必保留在表中。

有关详细信息，请参阅 ndb_restore--allow-pk-changes文档中的选项说明。（错误#26435136、错误#30383947、错误#30634010）

添加了 mysqld--ndb-log-fail-terminate的选项。使用时，这会导致 SQL 节点在无法记录所有行事件时终止。（漏洞 #21911930）

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

当标量子查询没有对附加了嵌入条件的表的外部引用时，可以独立于该表评估子查询；也就是说，子查询是不依赖的。NDB现在尝试在尝试从它所附加的表中检索任何行之前识别和评估这样的子查询，并使用在推送条件下获得的值，而不是使用提供该值的子查询。

在 MySQL 8.0.17 及更高版本中，MySQL 优化器将 NOT EXISTS查询NOT IN 转换为反连接。NDB现在可以将它们下推到数据节点。

这可以在表上没有未推送的条件时完成，并且查询满足要向下推送外部连接所必须满足的任何其他条件。

重要变更；NDB 磁盘数据： 表不支持在线更改表空间 NDB。现在，对于一个 NDB表，该语句 是明确不允许的。 ALTER TABLE ndb_table ... ALGORITHM=INPLACE, TABLESPACE=new_tablespace

作为此修复的一部分， ndb_desc实用程序的输出得到改进，以包括表空间名称和NDB正在使用的表的 ID。（缺陷号 31180526）

删除索引时在索引数组中使用了错误的索引。对于具有 64 个索引的表，这导致未初始化的内存被释放。当在删除后的任何稍后时间创建新索引时，此问题也会导致内存泄漏。（缺陷号 31408095）

删除了ndb_restore对 NDBCLUSTER插件 的不必要依赖 。（缺陷号 31347684）

由于临时错误（例如元数据锁获取失败）而导致自动同步失败的对象会简单地从检测到的对象列表中删除，从而使此类对象有资格在稍后重试同步并有望成功的周期中进行检测。这种尽力而为的方法适用于默认的自动同步行为，但在使用ndb_metadata_sync系统变量时并不理想，它会触发所有元数据的同步，并且在同步完成时自动设置为 false 以指示已完成.

当临时错误持续相当长的时间时，发生的事情是元数据同步可能比预期花费更长的时间，并且在极端情况下，可能会无限期挂起，等待用户操作。一种这样的情况发生在使用带有 恢复元数据选项的ndb_restore--disable-indexes时，当同步过程进入检测的恶性循环并且由于缺少索引导致同步尝试失败，直到使用 ndb_restore --rebuild-indexes重建索引。

此问题的解决方法是，无论何时 ndb_metadata_sync设置为 true，在同步失败 10 次并出现临时错误后排除对象，方法是将这些错误升级为永久错误，以防止停滞。这是通过维护此类对象的列表来完成的，该列表包括每个此类对象已被重试的次数的计数。此列表的验证在更改检测期间以与排除列表的验证类似的方式执行。（缺陷号 31341888）

NDB 8.0 不支持 32 位平台。从此版本开始，构建过程会检查系统架构，如果不是 64 位则中止。（缺陷号 31340969）

数据节点上面向页面的分配分为九个资源组，一些页面专用于它们自己，一些页面专用于共享全局内存，可以由任何资源组分配。为了防止查询内存资源组剥夺其他更重要的资源组，例如资源的事务内存，查询内存的分配以低优先级执行，不允许使用最后 10% 的共享全局内存。此更改是由 NDB 8.0.15 中完成的池化工作引入的。

随后，观察到只有在没有页面被使用时，查询内存保持不可访问的共享全局内存页数的计算才是正确的，也就是 LateAlloc数据节点参数被禁用（0）时的情况。

此修复更正了 LateAlloc启用时执行的计算。（缺陷号 31328947）

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

多线程还原能够比以前的单线程还原驱动更大的集群负载，尤其是在还原数据文件时。为避免与负载相关的问题，为ndb_restore实例指定的插入操作并行度 在部分线程之间平均分配，以便多线程实例具有与单线程实例相似的事务和操作并行度。

除法错误导致某些部分线程的插入操作并行度低于应有水平，从而导致恢复速度低于预期。此修复可确保多线程ndb_restore 实例中的所有部分线程获得平等份额的并行性。（缺陷号 31256989）

DUMP 1001 ( DumpPageMemoryOnFail) 现在会在由于资源限制导致页面分配失败时打印出有关数据节点页面内存管理器内部状态的信息。（缺陷号 31231286）

用于跟踪分配的内部对象和决定何时释放它们而生成的统计数据NDB计算不正确，导致资源使用阈值比预期高 50%。此修复程序纠正了该问题，并且应该可以减少内存使用量。（缺陷号 31127237）

NDB Cluster 中包含并由自动安装程序使用的 Dojo 工具包已升级到版本 1.15.3。（缺陷号 31029110）

ndb_mgmd 返回的打包版本 1 配置文件 在升级到 NDB 8.0 后可能包含重复的条目，这使得该文件与使用版本 1 的客户端不兼容。发生这种情况是因为处理向后兼容性的代码假定每个条目中的条目部分在与默认部分合并时已经排序。为了解决这个问题，我们现在确保在合并之前执行这种排序。（缺陷号 31020183）

在执行任何 SHUTDOWN、 ALL STOP或 ALL RESTART管理命令时，不同的节点可能会尝试在不同的全局检查点索引 (CGI) 边​​界上停止。如果他们成功这样做，那么随后的系统重启会比正常情况下慢，因为任何具有较早停止 GCI 的节点都必须作为该过程的一部分进行接管。当节点在第一个 GCI 边界上失败导致幸存节点不可行时，幸存节点遭受仲裁失败；这具有导致此类节点在正确的 GCI 停止的积极效果，但可能会引起虚假错误或类似错误。

为避免此类问题，现在在计划关闭期间执行额外的同步，以减少不同数据节点尝试在不同 GCI 关闭的可能性，以及在系统重启期间使用不必要的节点接管。（缺陷号 31008713）

在升级期间，客户端可以连接到 NDB 8.0 数据节点而无需指定多传输器实例 ID，因此该 ID 默认为 -1。由于假设这只会发生在具有单个传输器的节点启动状态，因此节点可能会在重启期间挂起。（缺陷号 30899046）

当 NDB 集群从不支持数据字典的版本升级到支持数据字典的版本时，在较新的 SQL 节点上执行的任何 DDL 都没有正确分发到较旧的节点。此外，在 DDL 执行期间生成的较新 SDI 会被任何尚未升级的数据节点忽略。这两个问题导致模式状态在不同 NDB 软件版本的节点之间不一致。

我们通过阻止任何影响 NDB 数据对象的 DDL 来解决此问题，同时从以前的 NDB 版本升级到具有数据字典支持的版本正在进行中。（缺陷号 30877440）

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

该mysql.ndb_schema表在内部用于 SQL 节点之间的模式分布，已在 NDB 8.0 中进行了修改。当集群从旧版本的 NDB 升级时，第一个要升级的 SQL 节点会更新此表的定义以匹配 NDB 8.0 GA 版本使用的定义。（为此，NDB 现在使用 8.0.21 作为截止版本。）这是通过删除现有表并使用较新的定义重新创建它来完成的。还没有升级的SQL节点接收到这个ndb_schematable drop事件，进入只读模式，只有在升级后才能重新变为可写。

为了防止运行旧版本 NDB 的 SQL 节点进入只读模式，我们更改了 mysqld的升级行为，以便 ndb_schema仅当连接到集群的所有 SQL 节点都运行 8.0 GA 版本的 NDB 时才会更新表定义，因此具有更新的 ndb_schema表定义。这意味着，在升级到当前或任何更高版本期间， ndb_schema如果至少有一个旧版本的 SQL 节点连接到集群，则没有正在升级的 MySQL 服务器更新表。在整个升级过程中，任何运行旧版本 NDB 的 SQL 节点都保持可写。（错误#30876990，错误#31016905）

ndb_import没有正确处理 CSV 解析器错误发生在输入块而不是最终块中的情况。（缺陷号 30839144）

当mysqld升级到使用新 SDI 版本的版本时，所有NDB表都变得不可访问。这是因为，在升级期间，NDB表的同步依赖于反序列化打包到 NDB 字典中的 SDI；如果SDI格式比升级前的版本旧，如果格式与新版本不一样，则无法进行反序列化，导致无法在MySQL数据字典中创建表对象.

这是通过NDB 在必要时绕过 MySQL 服务器中的 SDI 版本检查以作为升级的一部分执行反序列化来解决的。（错误#30789293，错误#30825260）

当响应一个SCANTABREQ时，如果 API 节点知道扫描应该只在一个片段上工作，它可以提供一个分布键，在这种情况下，分布键应该是片段 ID，但在某些情况下，使用分区键的散列相反，导致 DBTC. （缺陷号 30774226）

在ndb_import中 发现的几个内存泄漏已被删除。（错误#30756434，错误#30727956）

DEFINE_BACKUP_REQ 备份中的主节点在收到对信号 的重复回复时意外关闭。这些发生在主节点以外的数据节点在备份期间出错时，备份主 DEFINE_BACKUP_REF节点通过代表丢失的节点向自己发送信号来处理这种情况，这导致从同一节点接收到两个回复（CONF来自关闭之前的问题节点和REF 代表该节点的主节点发出的信号），即使主节点只希望每个节点有一个回复。START_BACKUP_REQ和 STOP_BACKUP_REQ信号 也遇到过这种情况。

在这种情况下，当错误是计划外节点关闭的结果时，通过允许重复回复来解决这个问题。（缺陷号 30589827）

使用 更新NDB_TABLE注释选项 ALTER TABLE时，在创建表时已设置为非默认值但未在ALTER TABLE语句中指定的其他选项可以重置为其默认值。

有关详细信息，请参阅设置 NDB 注释选项。（缺陷号 30428829）

删除了在ndb_import 实用程序 中发现的内存泄漏。（缺陷号 29820879）

当使用具有非二进制（区分大小写）相等条件的主键时，节点重新启动期间对片段副本的操作处理不当可能导致强制关闭，或片段副本之间的内容分歧。（缺陷 #98526，缺陷 #30884622）