重要的变化:上的63字节限制NDB数据库和表名称已被删除。与使用其他MySQL存储引擎时一样，这些标识符现在可能最多占用64个字节。有关更多信息，请参见在NDB集群8.0中解决了以前的NDB集群问题．(Bug #44940, Bug #11753491, Bug #27447958)

重要的变化:实现了NDB_STORED_USER特权，它允许在连接到给定NDB集群的所有SQL节点之间共享用户、角色和特权。这取代了NDB 7.6和更早版本的NDB集群中的分布式授权表机制，该机制在NDB 8.0.16中被删除，原因是它与MySQL 8.0中对MySQL特权系统的更改不兼容。

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

NDB_STORED_USER是否可以授予保留帐户以外的用户和角色，如mysql.session@localhost或mysql.infoschema@localhost．角色可以共享，但将共享角色分配给用户不会导致该用户被共享;的NDB_STORED_USER权限必须显式地授予用户，以便在NDB集群SQL节点之间共享该用户。

的NDB_STORED_USER特权总是全局的，必须通过使用来授予* *。．只有当MySQL服务器启用对NDBCLUSTER存储引擎。

有关使用信息，请参见NDB_STORED_USER．使用NDB_STORED_USER的分布式MySQL特权，有关于如何操作的附加信息NDB_STORED_USER特权同步工作。有关此更改如何影响从以前版本升级到NDB 8.0的信息，请参见升级和降级新db集群．

参考文献:参见Bug #29862601, Bug #29996547。

重要的变化:类的最大行大小NDB表从14000字节增加到30000字节。

和以前一样，只有a的前264字节团或文本列计数计入总数。

类中固定宽度列的最大偏移量NDB表为8188字节;这与之前的NDB集群版本相同。

有关更多信息，请参见NDB集群中数据库对象关联限制．

参考文献:参见Bug #29485977, Bug #29024275。

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

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

有关更多信息，请参见升级和降级新db集群．

重要的变化:本版本将单个NDB集群支持的最大数据节点数从48个提高到144个。支持的数据节点id范围随着此增强而增加到1-144(包括)。

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

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

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

此更改还引入了用于数据节点的格式的新版本(v2)sysfile，它记录了诸如最后一个全局检查点索引、重新启动状态和每个节点的节点组成员关系等信息(参见NDB集群数据节点文件系统目录)．

NDB集群接口:的替代构造函数NdbInterpretedCode现在提供，它接受NdbRecord代替表格对象。(错误# 29852377)

NDB集群接口:NdbScanFilter: cmp ()下面是NdbInterpretedCode现在可以使用比较方法来比较表列值:

在使用任何这些方法时，要比较的表列值必须具有完全相同的类型，包括长度、精度和比例。此外，在所有情况下，零总是被这些方法认为小于任何其他值。您还应该注意，当用于比较表列值时，NdbScanFilter: cmp ()不支持的所有可能值BinaryCondition．

有关更多信息，请参见各个API方法的描述。

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

ndb_restore现在报告具体的NDB无法从备份加载表描述符时的错误编号和消息.ctl文件。当试图将从NDB集群软件的较新版本获取的备份恢复到运行较早版本的集群时，可能会发生这种情况——例如，当备份包含使用版本未知字符集的表时ndb_restore被用来恢复它。(错误# 30184265)

的输出转储1000在ndb_mgm客户端已扩展到提供关于数据页总使用情况的信息。(错误# 29841454)

参考文献:参见Bug #29929996。

NDB集群的条件下推功能扩展如下:

例子:假设有两张表t1而且t2如下所示创建:

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

下面的连接现在可以下推到数据节点:

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

支持的比较包括<，< =，>，> =，＝,<>．(错误# 29685643)

NDB集群现在使用table_name_fk_N作为内部生成的外键的命名模式，它类似于table_name_ibfk_N使用的模式InnoDB．(Bug #96508, Bug #30171959)

参考文献:参见: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对于64位手臂NDB集群源的cpu。目前，我们不为这个平台提供任何预编译的二进制文件。

的开始时间ndb_mgmd管理节点守护进程得到了如下显著改进:

列NDB现在可以在线重命名表，使用算法=原地．

参考文献:参见Bug #28609968。

重要的变化:因为当前的节点故障处理实现甚至不能保证单个事务的大小MaxNoOfConcurrentOperations在每一轮中完成时，该参数再次用于设置单个事务协调器实例中所有事务的并发操作总数的全局限制。(Bug #96617, Bug #30216204)

分区;NDB盘数据:中指定的表空间上缺少元数据锁，导致创建分区磁盘数据表失败创建表声明。(错误# 28876892)

NDB盘数据:表空间和数据文件不是紧密耦合的NDB，在这个意义上，他们是独立的NdbDictionary对象。方法恢复元数据时ndb_restore工具中，不能保证表空间及其关联的数据文件对象同时恢复。这可能导致在数据文件恢复到之前检测到表空间不匹配并自动同步到数据字典NDB．此问题也适用于日志文件组和撤消文件。

为了解决这个问题，元数据更改监控器现在只在表空间和日志文件组中实际存在对应的数据文件和undo文件时才提交表空间和日志文件组NDB．(错误# 30090080)

NDB盘数据:对象的创建和填充之后，数据节点失败NDB在磁盘上有列的表，但是在执行本地检查点之前，可能会丢失表空间中的行数据。(错误# 29506869)

NDB集群接口:NDB API示例ndbapi_array_simple.cpp(见NDB API简单数组示例),ndbapi_array_using_adapter.cpp(见使用适配器的NDB API简单数组示例)直接分配给std::向量数组而不是使用push_back方法()呼吁这样做。(错误# 28956047)

MySQL NDB ClusterJ:如果ClusterJ被部署为一个多模块web应用程序的单独模块，当应用程序试图创建一个域对象的新实例时，会出现异常illegalargumentexception:非公共接口没有被给定的加载器定义被扔出来。这是因为ClusterJ总是尝试创建一个代理类，从这个代理类可以实例化域对象，而代理类是域接口和受保护对象的实现DomainTypeHandlerImpl::可终结接口。这两个接口的类装入器是不同的，因为它们属于运行在web服务器上的不同模块，所以当ClusterJ试图使用域对象接口的类装入器创建代理类时，会抛出上述异常。此修复使终结接口公共，以便web应用程序的类装入器能够访问它，即使它属于与域接口的模块不同的模块。(错误# 29895213)

MySQL NDB ClusterJ:ClusterJ在重新连接到NDB集群后，有时会出现段错误。这是由于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)

在备份布洛克，我们假设第一张唱片c_backups是本地检查点记录，但情况并不总是如此。现在NDB循环遍历记录c_backups来查找(正确的)LCP记录。(错误# 30080194)

在主节点接管期间，有可能在状态中结束LCP_STATUS_IDLE而其余的数据节点报告它们的状态为LCP_TAB_SAVED．事件的接收时，这会导致节点失败LCP_COMPLETE_REP信号，因为这是不期望在空闲时。在这种情况下，本地检查点处理的方式确保该节点以适当的状态结束(LCP_TAB_SAVED)．(错误# 30032863)

当MySQL服务器使用NDBCLUSTERsupport在Solaris/x86上运行，在模式分发过程中失败。问题的根本原因是在优化级别时，用于为该平台构建二进制文件的Developer Studio编译器出现了问题-xO2是使用。这个问题通过使用优化级别来解决-xO1而不是为NDBCLUSTER为Solaris/x86编译。(错误# 30031130)

参考文献:参见Bug #28585914, Bug #30014295。

NDB使用free ()直接释放ndb_mgm_configuration而不是调用ndb_mgm_destroy_configuration ()，正确使用删除回收。(错误# 29998980)

默认配置节在解压缩到内存时没有设置配置节类型，这导致了内存泄漏，因为这意味着节析构函数不会销毁这些节的条目。(错误# 29965125)

时没有传播错误NDB未能发现表，原因是表格式较旧且不再支持，可能导致NDB处理程序无休止地重试发现操作，从而挂起。(Bug #29949096, Bug #29934763)

在升级一个NDB集群时，当一半的数据节点运行的是NDB 7.6，而其余的数据节点运行的是NDB 8.0，试图关闭运行的是NDB 7.6的节点时，导致一个节点失败检查FAILEDNODEPTR。P - > DBLQHFAI．(Bug #29912988, Bug #30141203)

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

在这种情况下，当事务正在进行时，表发现操作会失败。(错误# 29911440)

在执行本地检查点(LCP)时，一个表的模式版本被间歇性地读为0，导致NDBLCP处理处理表，就像它正在被丢弃一样。这可能通过以下方式影响离线索引的重建ndb_restore而桌子在TABLE_READ_ONLY状态。现在函数读取模式版本(getCreateSchemaVersion ())不再在表为只读时更改它。(错误# 29910397)

在模式分发期间，当SQL节点上发生错误时，有关此错误的信息将写入错误日志中，但是mysql客户端得知有问题的DDL语句不成功。现在，在这种情况下，客户机将显示一个或多个通用警告，以指示给定的模式分发操作没有成功，并在初始SQL节点的错误日志中提供进一步的信息。(错误# 29889869)

元数据同步和元数据更改检测期间推送到执行线程的错误和警告没有正确记录和清除。(错误# 29874313)

在线执行将普通列更改为存储生成列的操作，尽管不支持这种操作。(错误# 29862463)

push join with命令不总是按指定的顺序返回结果的行。当优化器使用有序索引提供排序，而索引使用表中的列作为推入连接的根时，就会发生这种情况。(错误# 29860378)

在本地检查点(lcp)备份块中发现并修复了一些问题，包括以下问题:

(错误# 29843373)

参考文献:参见Bug #29485977。

的requestInfo的长形式和短形式LQHKEYREQ信号有不同的定义;在短版本中用于键长度的位被重用为长版本中的标志，因为键长度隐含在信号的长版本的段长度中，但对于长版本是可能的LQHKEYREQ在这些相同的位中包含键长度的信号，这可能被接收的本地查询处理程序误解，从而可能导致错误。现在已经实施了检查，以确保这种情况不再发生。(错误# 29820838)

被抛售股票的名单只能容纳一只被抛售股票NDB_SHARE实例，防止NDB_SHARE具有相同键的实例不会被丢弃多次，而处理程序持有对这些实例的引用NDB_SHARE实例。这干扰了跟踪已分配的内存，以及如果能够释放它mysqld在所有处理程序未释放对共享的引用时关闭。为了解决此问题，已将已删除的共享列表更改为使用允许多个共享的列表类型NDB_SHARE用相同的键同时存在。(Bug #29812659, Bug #29812613)

删除一个ndb_restore类定义的表名上的编译时依赖项ndbcluster插件。(错误# 29801100)

当在多个SQL节点上并行创建表时，结果是在检查表是否存在和打开表之间出现竞争条件，这导致如果不存在，则创建表错误1失败。这是两个问题的结果，在这里描述了他们的修复:

此外，这还修复了创建索引有时也会因Error 1而失败的相关问题。(Bug #29793534, Bug #29871321)

以前，对于push条件，每个请求都发送到NDB的新实例生成NdbInterpretedCode．当连接表时，很可能为查询计划中第一个表之后的所有表生成多个请求;如果已推条件与查询计划中的前一个表没有依赖关系，则相同的实例NdbInterpretedCode为每个请求生成，浪费了大量的CPU周期。现在已经确定了这些推入条件和所需的推入条件NdbInterpretedCode对象只生成一次，并在为该表发送的每个请求中重用，而不需要每次生成新的代码。

这种变化也使得扫描滤镜太大在查询优化期间要检测和设置的错误，这纠正了查询计划不准确的情况，因为稍后必须在执行阶段撤销指示的条件推送。(错误# 29704575)

的一些例子NdbScanFilter使用在压下条件下产生不适当的原因浮动在内部表示为长度为零的值。这导致返回的行数超过了预期NDB的值所示Ndb_api_read_row_count．当生成扫描过滤器失败时，mysqld会重新评估条件，在这种情况下，最终结果仍然是正确的，但推送条件所带来的任何性能收益都会丢失。(错误# 29699347)

在创建表时，NDB不能总是正确地确定它是否超过了允许的最大记录大小。(错误# 29698277)

NDB索引统计信息是基于有序索引的一个碎片的拓扑计算的;在任何特定索引中选择的片段都是在创建索引时决定的，无论是在索引最初创建时，还是在节点或系统重新启动时在本地重新创建索引时。这种计算部分基于索引中的片段数量，当表被重组时，片段数量可能会发生变化。这意味着，下次重新启动节点时，该节点可能会选择一个不同的片段，这样就不会使用任何片段、一个片段或两个片段来生成索引统计信息，从而导致错误分析表．

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

作为初始化模式分布的一部分，每个数据节点必须维护一个订阅者位图，提供关于当前订阅到该数据节点的API节点的信息。以前，位图的大小是硬编码的MAX_NODES(256)，这意味着当集群的节点比这个值少得多时，可能会分配大量内存，但不会使用。现在位图的大小是通过检查集群配置文件中使用的最大API节点ID来确定的。(错误# 29270539)

移除mysql_upgrade效用和它的替代品mysqld——初始化意味着升级过程比以前执行得更早，可能更早NDB已完全准备好处理查询。这导致了MySQL特权表的迁移NDB来InnoDB失败。(错误# 29205142)

在重新启动期间，当数据节点已经启动但尚未选举主席时，管理服务器收到一个节点ID已经在使用错误，这导致了过多的重试和记录。这个问题通过引入一个新的错误1705得到了解决还没有准备好进行连接分配在这种情况下。

在重新启动期间，当数据节点尚未完成节点故障处理时，出现伪错误事件解释分配nodeID失败返回错误。通过添加一个检查来检测不完整的节点启动并返回错误1703，可以解决这个问题节点故障处理未完成代替。

作为此修复的一部分，重试的频率已经减少not ready to alloc nodeID错误，为测试目的添加了一个错误插入来模拟缓慢的重新启动，并且日志消息已经重新编写，以表明相关的节点ID分配错误是轻微的，只是临时的。(错误# 27484514)

NDB在Windows和macOS平台上并不总是使用混合大小写处理表名lower_case_table_names= 2。(错误# 27307793)

选择选中的事务协调器的过程”生活”数据节点，但不一定是那些实际可用的。(错误# 27160203)

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

通过确保二进制日志记录线程立即获得全局模式锁或返回错误，这一问题得到了解决。作为这项工作的一部分，一个新的OperationOptions国旗OO_NOWAIT在NDB API中也实现了。