重要更改：数据库和表名 的 63 字节限制NDB已被删除。这些标识符现在最多可能占用 64 个字节，就像使用其他 MySQL 存储引擎时一样。有关更多信息，请参阅 NDB Cluster 8.0 中已解决的先前 NDB Cluster 问题。（错误#44940，错误#11753491，错误#27447958）

重要更改： 实现了NDB_STORED_USER 特权，允许在附加到给定 NDB Cluster 的所有 SQL 节点之间共享用户、角色和特权。这取代了 NDB 7.6 和早期版本的 NDB Cluster 的分布式授权表机制，由于与 MySQL 8.0 中对 MySQL 权限系统所做的更改不兼容，它在 NDB 8.0.16 中被删除。

一旦连接到集群，具有此权限的用户或角色及其（其他）权限就会传播到 MySQL 服务器（SQL 节点）。对用户或角色的权限所做的更改会立即与所有连接的 SQL 节点同步。

NDB_STORED_USER可以授予除保留帐户以外的用户和角色，例如 mysql.session@localhost或 mysql.infoschema@localhost。一个角色可以被共享，但是将一个共享角色分配给一个用户并不会导致这个用户被共享；NDB_STORED_USER 必须显式授予用户权限，以便在 NDB Cluster SQL 节点之间共享用户 。

该NDB_STORED_USER特权始终是全局的，必须使用ON *.*. 仅当 MySQL 服务器启用对NDBCLUSTER存储引擎的支持时，才能识别此权限。

有关使用信息，请参阅 的说明 NDB_STORED_USER。 特权同步和 NDB_STORED_USER有关于特权同步如何工作的附加信息NDB_STORED_USER 。有关此更改如何影响从以前版本升级到 NDB 8.0 的信息，请参阅升级和降级 NDB Cluster。

参考资料：另请参阅：Bug #29862601、Bug #29996547。

重要更改：表 的最大行大小NDB从 14000 字节增加到 30000 字节。

和以前一样，只有 aBLOB 或TEXT列的前 264 个字节计入此总数。

表的固定宽度列的最大偏移量为 NDB8188 字节；这也与以前的 NDB Cluster 版本没有变化。

有关更多信息，请参阅 与 NDB Cluster 中的数据库对象关联的限制。

参考资料：另请参阅：Bug #29485977、Bug #29024275。

重要变化： NDB 管理服务器的缓存配置文件实现了一种新的二进制格式，旨在支持集群中比以前更多的节点。在此版本之前，配置文件最多支持 16381 个部分；这个数字增加到4G。

升级到新格式不需要任何手动干预，因为管理服务器（和其他集群节点）仍然可以读取旧格式。对于从这个版本或更高版本降级到 NDB 8.0.17 或更早版本，有必要在启动旧的管理服务器二进制文件之前删除二进制配置文件，或者使用该 --initial选项启动它。

有关更多信息，请参阅 升级和降级 NDB Cluster。

重要更改： 在此版本中，单个 NDB 集群中支持的最大数据节点数从 48 增加到 144。支持的数据节点 ID 的范围与此增强一起增加到 1-144，包括在内。

在以前的版本中，管理节点的推荐节点 ID 为 49 和 50。这些值仍然受支持，但如果使用，会将数据节点的最大数量限制为 142。因此，管理服务器的推荐节点 ID 值现在是145 和 146。

给定集群中所有类型的节点的最大支持总数为 255。此总数与以前的版本相比没有变化。

对于运行超过 48 个数据节点的集群，无法直接降级到仅支持 48 个数据节点的先前版本。在这种情况下，有必要将数据节点的数量减少到 48 个或更少，并确保所有数据节点使用小于 49 的节点 ID。

此更改还引入了用于数据节点的格式的新版本（v2）sysfile，它记录了每个节点的最后一个全局检查点索引、重启状态和节点组成员身份等信息（请参阅 NDB Cluster 数据节点文件系统目录） .

NDB Cluster APIs：NdbInterpretedCode现在提供了 一个替代构造函数 NdbRecord代替 Table对象。（漏洞#29852377）

NDB Cluster APIs： NdbScanFilter::cmp()现在可以使用以下NdbInterpretedCode 比较方法来比较表列值：

使用这些方法中的任何一种时，要比较的表列值的类型必须完全相同，包括长度、精度和小数位数。此外，在所有情况下，NULL这些方法始终认为 小于任何其他值。您还应该知道，当用于比较表列值时， NdbScanFilter::cmp()不支持所有可能的值 BinaryCondition。

有关详细信息，请参阅各个 API 方法的说明。

NDB 客户端程序：ndb_delete_all实用程序对 的依赖NDBT已被删除。该库用于NDB开发测试，正常使用不需要。用户可见的变化是ndb_delete_all在其运行完成后不再打印 依赖此行为的应用程序应在升级到此版本时进行更新以反映此更改。 NDBT_ProgramExit - status

ndb_restoreNDB现在在无法从备份 .ctl文件报告特定的 当尝试将从较新版本的 NDB Cluster 软件获取的备份还原到运行较早版本的集群时，可能会发生这种情况 - 例如，当备份包含使用字符集的表时，该字符集对于 正在使用的ndb_restore版本是未知的恢复它。（缺陷号 30184265）

ndb_mgmDUMP 1000客户端中 的输出已扩展为提供有关总数据页使用情况的信息。（漏洞#29841454）

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

NDB Cluster 的条件下推功能已扩展如下：

示例：假设有两个表 t1并按t2如下所示创建：

CREATE TABLE t1 (a INT, b INT, c CHAR(10), d CHAR(5)) ENGINE=NDB;
CREATE TABLE t2 LIKE t1;

现在可以将以下连接下推到数据节点：

SELECT * FROM t1 JOIN t2 ON t2.a < t1.a+10;
SELECT * FROM t1 JOIN t2 ON t2.a = t1.a+t1.b;
SELECT * FROM t1 JOIN t2 ON t2.a = t1.a+t1.b;
SELECT * FROM t1 JOIN t2 ON t2.d = SUBSTRING(t1.c,1,5);
SELECT * FROM t1 JOIN t2 ON t2.c = CONCAT('foo',t1.d,'ba');

支持的比较有<, <=, >, >=,=和 <>。（漏洞#29685643）

NDB Cluster 现在使用 as 内部生成的外键的命名 模式 ，这类似于 . （缺陷 #96508，缺陷 #30171959）table_name_fk_Ntable_name_ibfk_NInnoDB

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

添加了 系统变量以控制在尝试从数据字典的元数据ndb_schema_dist_lock_wait_timeout 更新 SQL 节点的本地数据字典以获取当前正在使用的一个或多个表时等待架构锁释放 的时间。NDB如果这个同步在这个时间结束时还没有发生，SQL 节点返回一个警告，模式分发没有成功；下一次访问分配失败的表时，NDB再次尝试同步表元数据。

NDB元数据更改监视器线程提交的表对象现在会自动检查是否存在任何不匹配，并由NDB二进制日志记录线程进行同步。本次发布新增状态变量 Ndb_metadata_synced_count ，显示自动同步的对象数量；可以通过检查集群日志来查看哪些对象已被同步。此外，新的状态变量 Ndb_metadata_blacklist_size 指示同步失败的对象数。

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

现在可以从 NDB Cluster 源构建NDB64 位 ARMCPU。目前，我们不为此平台提供任何预编译的二进制文件。

ndb_mgmd管理节点守护进程 的启动时间已得到显着改善，如下所示：

NDB现在可以在线重命名表 的列，使用ALGORITHM=INPLACE.

参考资料：另请参阅：错误 #28609968。

重要变化： 由于当前节点故障处理的实现方式无法保证 MaxNoOfConcurrentOperations 每一轮完成即使是单个大小的事务，因此再次使用该参数对单个事务内所有事务的并发操作总数进行全局限制事务协调器实例。（缺陷 #96617，缺陷 #30216204）

分区；NDB 磁盘数据： 由于 CREATE TABLE语句中指定的表空间缺少元数据锁，分区磁盘数据表的创建失败。（漏洞#28876892）

NDB 磁盘数据： 表空间和数据文件在 中没有紧密耦合 NDB，因为它们由独立的NdbDictionary 对象表示。因此，当使用 ndb_restore工具恢复元数据时，无法保证同时恢复表空间及其关联的数据文件对象。这导致有可能检测到表空间不匹配并在数据文件恢复到之前自动同步到数据字典 NDB。此问题也适用于日志文件组和撤消文件。

为解决此问题，元数据更改监视器现在仅当表空间和日志文件组的相应数据文件和撤消文件实际存在于 NDB. （缺陷号 30090080）

NDB 磁盘数据： 当数据节点在创建和填充 NDB磁盘上有列的表后失败时，但在执行本地检查点之前，可能会丢失表空间中的行数据。（漏洞 #29506869）

NDB Cluster API： NDB API 示例 ndbapi_array_simple.cpp（请参阅 NDB API 简单数组示例）和 ndbapi_array_using_adapter.cpp（请参阅 使用适配器的 NDB API 简单数组示例）直接对std::vector数组进行分配，而不是使用push_back()调用来这样做。（缺陷号 28956047）

MySQL NDB ClusterJ： 如果 ClusterJ 被部署为多模块 Web 应用程序的单独模块，当应用程序尝试创建域对象的新实例时， java.lang.IllegalArgumentException: non-public interface is not defined by the given loader会抛出异常。这是因为 ClusterJ 总是试图创建一个代理类，从中可以实例化领域对象，而代理类是领域接口和受保护对象的实现DomainTypeHandlerImpl::Finalizable 界面。这两个接口的类加载器在案例中是不同的，因为它们属于运行在 web 服务器上的不同模块，所以当 ClusterJ 试图使用域对象接口的类加载器创建代理类时，会抛出上述异常. 此修复使Finalization接口公开，以便 Web 应用程序的类加载器能够访问它，即使它属于与域接口不同的模块。（错误号 29895213）

MySQL NDB ClusterJ： 在重新连接到 NDB Cluster 后，ClusterJ 有时会因分段错误而失败。这是由于 ClusterJ 重用了旧连接中的旧数据库元数据对象。通过修复，这些对象在重新连接到集群之前被丢弃。（漏洞#29891983）

微秒计算错误导致内部 ndb_milli_sleep()函数睡眠时间过短。（缺陷号 30211922）

数据节点启动后，其配置的 95% DataMemory应可用于正常数据，5% 可用于紧急情况。在节点启动过程中，其配置DataMemory的所有数据都可用于数据，以最大程度地减少由于某些动态内存结构为相同数据使用更多页面而导致数据内存耗尽而导致节点数据恢复失败的风险。节点已停止。例如，哈希表在重新启动期间的增长与之前不同，因为插入表的顺序与历史顺序不同。

当检查使用的数据内存加上备用数据内存不超过设置的值时，此错误报告中出现的问题DataMemory在备用内存保留点失败。当保留备用页面时，数据节点的状态从开始过渡到开始时发生这种情况。在计算了用于备用内存的保留页数，然后计算了为此使用的共享页数（即来自共享全局内存的页数）后，已分配的保留页数未被考虑在内。（缺陷号 30205182）

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

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

无法使用ndb_restore和从 NDB 8.0 集群获取的备份来恢复到运行 NDB 7.6 的集群。（缺陷号 30184658）

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

启动时，数据节点的本地 sysfile 在第一个完成的本地检查点和启动阶段 50 之间没有更新。（缺陷 #30086352）

在BACKUP块中，假设第一个记录 c_backups是本地检查点记录，但情况并非总是如此。现在NDB循环遍历中的记录c_backups以查找（正确的）LCP 记录。（缺陷号 30080194）

在 master 的节点接管期间，有可能在 state 结束，LCP_STATUS_IDLE而其余数据节点将其状态报告为 LCP_TAB_SAVED. 这导致节点在尝试处理 LCP_COMPLETE_REP信号接收时出现故障，因为在空闲时这不是预期的。现在在这种情况下，本地检查点处理以确保该节点以正确状态 ( LCP_TAB_SAVED) 完成的方式完成。（缺陷号 30032863）

当支持构建的 MySQL 服务器NDBCLUSTER 在 Solaris/x86 上运行时，它在架构分发期间失败。问题的根本原因是在使用优化级别时用于为该平台构建二进制文件的 Developer Studio 编译器存在问题-xO2。此问题已通过使用优化级别 -xO1而不是 NDBCLUSTER为 Solaris/x86 构建来解决。（缺陷号 30031130）

参考资料：另请参阅：Bug #28585914、Bug #30014295。

NDBfree()直接用于解除分配对象ndb_mgm_configuration而不是调用 ndb_mgm_destroy_configuration()，后者正确delete用于解除分配。（漏洞#29998980）

默认配置节在解压缩到内存中时没有设置配置节类型，这导致内存泄漏，因为这意味着节析构函数不会破坏这些节的条目。（漏洞 #29965125）

NDB由于表格式陈旧且不再受支持而未能发现表 时，不会传播任何错误，这可能导致NDB处理程序无休止地重试发现操作，从而挂起。（错误#29949096，错误#29934763）

在 NDB Cluster 升级过程中，当一半数据节点运行 NDB 7.6 而其余数据节点运行 NDB 8.0 时，尝试关闭那些运行 NDB 7.6 的节点会导致一个节点出现故障并出现错误CHECK FAILEDNODEPTR.P-> DBLQHFAI。（错误#29912988，错误#30141203）

在正在进行的事务中更改表会导致表发现操作，从而导致事务过早提交；此外，作为同一事务的一部分执行进一步更新时，不会返回任何错误。

现在在这种情况下，当事务正在进行时，表发现操作失败。（漏洞#29911440）

执行本地检查点 (LCP) 时，表的架构版本间歇性读取为 0，这导致 NDBLCP 处理将该表视为正在删除。当表处于该状态时，这可能会影响通过ndb_restore离线重建索引。TABLE_READ_ONLY现在读取架构版本 ( getCreateSchemaVersion()) 的函数不再在表为只读时更改它。（缺陷号 29910397）

当模式分发期间 SQL 节点上发生错误时，相关信息将写入错误日志中，但mysql客户端没有提供有关 DDL 语句不成功的指示。现在在这种情况下，客户端会显示一个或多个一般警告，以指示给定的模式分发操作未成功，并在原始 SQL 节点的错误日志中提供更多信息。（漏洞#29889869）

在元数据同步和元数据更改检测期间推送到执行线程的错误和警告未正确记录和清除。（缺陷号 29874313）

将普通列更改为存储的生成列是联机执行的，即使这不受支持。（漏洞#29862463）

推送连接ORDER BY并不总是以指定的顺序返回结果的行。当优化器使用有序索引提供排序并且索引使用表中的列作为推送连接的根时，可能会发生这种情况。（缺陷号 29860378）

发现并修复了本地检查点 (LCP) 备份块中的许多问题，包括：

（漏洞#29843373）

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

requestInfo信号的长格式和短格式的字段 有LQHKEYREQ不同的定义；用于短版本中密钥长度的位在长版本中被重新用于标志，因为密钥长度隐含在长版本信号的部分长度中，但长LQHKEYREQ 信号有可能在这些相同的部分中包含密钥长度位，这可能会被接收本地查询处理程序误解，从而可能导致错误。现在已经实施检查以确保不再发生这种情况。（缺陷号 29820838）

NDB_SHARE对于每个键，已 删除的共享列表只能包含一个已删除 的实例，这可以防止NDB_SHARE在处理程序持有对这些实例的引用时多次删除具有相同键的NDB_SHARE实例。如果mysqld关闭而所有处理程序都没有释放它们对共享的引用，这会干扰跟踪分配的内存并能够释放它。为解决此问题，删除的共享列表已更改为使用一种列表类型，该列表类型允许 NDB_SHARE同时存在多个具有相同密钥的共享列表。（错误#29812659，错误#29812613）

删除了插件定义的对表名的ndb_restore编译时依赖性 ndbcluster。（漏洞 #29801100）

在多个 SQL 节点上并行创建表时，结果是检查表是否存在和打开表之间的竞争条件，导致 CREATE TABLE IF NOT EXISTS失败并显示错误 1。这是两个问题的结果，在此处描述了它们的修复：

此外，这修复了创建索引有时也会失败并出现错误 1 ​​的相关问题。（错误 #29793534，错误 #29871321）

以前，对于推送条件， NDB针对给定表发送到的每个请求都会导致生成 NdbInterpretedCode. 连接表时，很有可能对查询计划中第一个表之后的所有表生成多个请求；如果推送的条件与查询计划中的先前表没有依赖关系， NdbInterpretedCode则会为每个请求生成相同的实例，从而浪费大量 CPU 周期。现在，此类推送条件已确定，所需 NdbInterpretedCode对象仅生成一次，并可重复用于为此表发送的每个请求，而无需每次都生成新代码。

此更改还可以在查询优化期间检测和设置扫描过滤器太大的错误，这纠正了显示的查询计划不准确的情况，因为稍后必须在执行阶段撤消指示的条件推送。（漏洞 #29704575）

NdbScanFilter 由于 FLOAT值在内部表示为零长度，因此无法正确生成用于下推条件的 某些实例。这导致从 返回的行数超过预期 NDB，如 的值所示 Ndb_api_read_row_count。虽然当生成扫描过滤器失败时 mysqld 重新评估了条件，但在这种情况下最终结果仍然是正确的，但是推送条件所期望的任何性能增益都丢失了。（漏洞#29699347）

创建表时，NDB总是不能正确判断是否超过了允许的最大记录大小。（缺陷号 29698277）

NDB索引统计信息是根据有序索引的一个片段的拓扑结构计算的；在任何特定索引中选择的片段是在索引创建时决定的，无论是在最初创建索引时，还是在节点或系统重启在本地重新创建索引时。此计算部分基于索引中的片段数，重组表时片段数可能会发生变化。这意味着，下次重启该节点时，该节点可能会选择不同的分片，从而不使用分片、使用一个分片或使用两个分片来生成索引统计信息，从而导致ANALYZE TABLE.

这个问题通过修改在线表重组来立即重新计算选择的片段来解决，这样所有节点在任何后续重启之前和之后都是对齐的。（漏洞#29534647）

作为初始化模式分发的一部分，每个数据节点必须维护一个订阅者位图，提供有关当前订阅该数据节点的 API 节点的信息。以前，位图的大小被硬编码为 MAX_NODES(256)，这意味着当集群的节点数明显少于此值时，可能会分配大量内存但从未使用过。现在位图的大小是通过检查集群配置文件中使用的最大 API 节点 ID 来确定的。（缺陷号 29270539）

删除mysql_upgrade实用程序并将其替换为mysqld --initialize意味着升级过程比以前执行得更早，可能在NDB完全准备好处理查询之前。这导致 MySQL 特权表从NDB到的InnoDB迁移失败。（漏洞 #29205142）

在数据节点已经启动但尚未选出总统的重启期间，管理服务器收到一个 节点 ID 已在使用错误，这导致过多的重试和日志记录。这是通过引入新错误 1705 Not ready for connection allocation yet for this case 来解决的。

在数据节点尚未完成节点故障处理的重新启动期间，返回虚假的Failed to allocate nodeID错误。这是通过添加检查来检测未完成的节点启动并返回错误 1703节点故障处理未完成 来解决的。

作为此修复的一部分，针对未准备好分配节点 ID错误 的重试频率已降低，已添加错误插入以模拟缓慢重启以用于测试目的，并且日志消息已改写以指示相关节点 ID 分配错误很小，而且只是暂时的。（漏洞#27484514）

NDB在 Windows 和 macOS 平台上，并不总是使用大小写混合的表名与 lower_case_table_names= 2 一致。（缺陷 #27307793）

选择事务协调器的过程会检查 “实时”数据节点，但不一定检查那些实际可用的节点。（漏洞 #27160203）

自动元数据同步机制要求二进制日志线程在安全同步对象之前获取全局模式锁。当另一个线程同时获取此锁时，二进制日志记录线程最多等待 TransactionDeadlockDetectionTimeout 几毫秒，然后如果获取锁不成功则返回失败，这是不必要的并且会对性能产生负面影响。

这已通过确保二进制日志记录线程获取全局模式锁或立即返回错误来解决。作为这项工作的一部分， NDB API 中还实现了 一个新OperationOptions 标志。OO_NOWAIT