不兼容的更改:在连接到NDB集群的MySQL服务器之间分配特权，就像在NDB 7.6和更早的版本中实现的那样，在NDB 8.0中无法发挥作用，而且大多数支持这些特权的代码现在已经被删除了。当一个mysqld中检测这样的表NDB方法创建本地的影子表InnoDB存储引擎;这些影子表是在连接到NDB集群的每个MySQL服务器上创建的。特权表使用NDB不使用存储引擎进行访问控制;一旦所有连接的MySQL服务器升级，特权表NDB可以拆下安全使用吗ndb_drop_table．

从兼容性角度看,ndb_restore——restore-privilege-tables仍然可以用于将NDB集群上一个版本的备份中的分布式特权表恢复到运行NDB 8.0的集群。这些表的处理方法如上段所述。

有关从以前的NDB集群版本系列升级到NDB 8.0的更多信息，请参见升级和降级新db集群．

不兼容的更改:的一致性InnoDB,NDB存储引擎现在使用生成的约束名约束象征子句未指定，或约束关键字不带参数象征．在以前的NDB版本中,NDB使用了外键index_name价值。

上面描述的这个更改可能会为依赖于前面外键约束命名行为的应用程序引入不兼容性。(错误# 29173134)

包装:此版本的Docker映像可以从https://hub.docker.com/r/mysql/mysql-cluster/．(Bug #96084, Bug #30010921)

事务协调器中的资源分配(参见DBTC块)现在使用动态内存池执行。这意味着由数据节点配置参数决定的资源分配，例如在交易参数而且事务临时存储现在对其进行限制，以免超过事务协调器可用的总资源。

作为这项工作的一部分，控制事务资源的几个新的数据节点参数DBTC，这里列出的，也已经添加。有关这些新参数的更多信息，请参见事务资源分配参数．(Bug #29164271, Bug #29194843)

参考文献:参见:Bug #29131828。

NDB现在可以使用多个本地数据管理器(ldm)在单个数据节点上以并行方式执行备份。(以前，备份是跨数据节点并行执行的，但在数据节点进程中总是串行执行的。)类不需要特殊的语法开始备份命令的ndb_mgm客户端来启用该特性，但所有数据节点必须使用多个ldm。这意味着数据节点必须正在运行ndbmtd并且在进行备份之前，必须将它们配置为使用多个ldm(请参阅多线程配置参数(ndbmtd))．

的EnableMultithreadedBackup该版本中引入的数据节点参数默认是启用的(设置为1)。控件中的此参数设置为0，可以禁用多线程备份并强制创建单线程备份(ndbd违约)部分的集群全局配置文件(config.ini)．

ndb_restore现在还可以检测多线程备份并自动尝试并行恢复它。通过稍微修改通常的恢复过程，还可以将备份并行恢复到NDB集群的前一个版本。

有关获取和恢复在数据节点上使用并行创建的NDB集群备份的详细信息，请参见使用并行数据节点进行NDB备份,从并行执行的备份中恢复．(Bug #28563639, Bug #28993400)

的compile-cluster包含在NDB源代码分发不再支持源代码内构建。

建筑与CMake3现在由compile-cluster包含在NDB源分布。

作为自动同步机制的一部分，NDB现在实现了一个元数据更改监视线程，用于检测数据对象(如表、表空间和使用MySQL数据字典的日志文件组)的元数据所做的更改。此线程在后台运行，每60秒检查一次NDB字典和MySQL数据字典。

的值可以调整监视器轮询间隔ndb_metadata_check_interval系统变量，可通过设置完全禁用ndb_metadata_check来了。自那以后检测到不一致的次数mysqld最后一次启动显示为状态变量，Ndb_metadata_detected_count．

条件下推不再局限于谓词项，谓词项引用的是来自被推入条件的同一表的列值;现在还可以从推入条件引用查询计划中前面表中的列值。这使得数据节点可以过滤出更多的行(并行地)，只留下更少的工作由单个节点执行mysqld过程，该过程有望显著提高查询性能。

有关更多信息，请参见发动机状态下压优化．

重要的变化;NDB磁盘数据:, mysqldump试图转储时意外终止NDB磁盘数据表。这背后的原因是, mysqldump中与撤消日志缓冲区有关的信息额外的列的INFORMATION_SCHEMA。文件表，但该信息已在NDB 8.0.13中删除。该信息现在已恢复到额外的列。(错误# 28800252)

重要的变化:当使用与原集群不同的数据节点id恢复到集群时，ndb_restore试图打开节点ID为0对应的文件。为了防止这种情况发生——nodeid而且——backupid选项——这两个选项都没有默认值——现在都是调用时显式需要的ndb_restore．(错误# 28813708)

重要的变化:的默认值从这个版本开始ndb_log_bin现在系统变量是假．(错误# 27135706)

NDB磁盘数据:当日志文件组中有超过18个undo日志时，无法重新启动集群。(错误# 251155785)

参考文献:参见Bug #28922609。

NDB磁盘数据:并发创建表使用表空间的语句会导致元数据锁之间的死锁。这发生在Ndb_metadata_change_monitor在检测到元数据更改后，在表空间和日志文件组上获得排他元数据锁，因为每个排他元数据锁依次获得一个全局模式锁。此修复程序试图通过降级所使用的锁来解决该问题Ndb_metadata_change_monitor来MDL_SHARED_READ．(错误# 29175268)

参考文献:参见Bug #29394407。

NDB磁盘数据:的验证时返回的错误消息MaxNoOfOpenFiles相对于InitialNoOfOpenFilesFailed进行了改进，使用户更清楚地了解问题的性质。(错误# 28943749)

NDB磁盘数据:模式的分布修改表空间而且修改日志文件组如果引用的表空间或日志文件组在其数据字典中不存在，则MySQL服务器上的语句将失败。现在，在这种情况下，无论MySQL服务器之间最初是否存在不匹配，语句的效果都会被成功分配。(错误# 28866336)

NDB磁盘数据:重复执行改变表空间……添加数据文件对相同表空间的操作会导致数据节点挂起，并且在被手动杀死后无法重新启动。(错误# 22605467)

NDB集群api:NDB现在标识不需要减少锁争用的短期事务NdbBlob: close ()并且在解锁只会导致提交或中止事务之前执行额外的工作和往返的情况下(例如启用自动提交时)不再调用此方法。(错误# 29305592)

参考文献:参见Bug #49190, Bug #11757181。

NDB集群api:当最近失败的操作被释放时，指向它的指针被保留NdbTransaction无效，当访问时导致NDB API应用程序失败。(错误# 29275244)

NDB集群api:当NDB内核的SUMA块发送TE_ALTER事件，它不会跟踪事件的所有片段何时被发送。当NDB接收事件，它缓冲片段，并在所有片段都到达时处理事件。对于非常大的表定义，当传输和接收之间的时间可能跨越多个epoch时，可能会出现问题;在这段时间里,SUMA可以发送一个SUB_GCP_COMPLETE_REP信号，表明它已经发送了一个纪元的所有数据，尽管在本例中这并不完全正确，因为可能存在TE_ALTER事件仍在等待数据节点被发送。接待的SUB_GCP_COMPLETE_REP导致关闭该epoch的缓冲区。因此,当TE_ALTER最终到达时，NDB认为它是一个较早时期的副本，并默默地丢弃它。

我们通过确保SUMA内核块从不发送SUB_GCP_COMPLETE_REP对于任何纪元，其中有未发送的片段SUB_TABLE_DATA信号。

这个问题可能会对使用的NDB API应用程序产生影响TE_ALTER事件。(SQL节点不做任何使用TE_ALTER事件，所以它们和使用它们的应用程序不会受到影响。

中执行的push连接时DBSPJ块必须在查询执行期间存储关联id，因此在整个查询执行的生命周期中为这些关联id分配了内存，即使只有在生成结果集中最近的批时才需要这些特定的关联id。后续批次需要存储和分配额外的关联id;因此，如果查询需要足够长的时间才能完成，这将导致查询内存耗尽(错误20008)。在这种情况下，只为当前结果批处理的生命周期分配内存，并在批处理完成后释放并供重用。(错误# 29336777)

参考文献:参见Bug #26995027。

类型的固定长度字符串进行比较或散列时NO_PAD排序，任何尾随填充字符(通常是空格)被发送到散列和比较函数，这样它们就变得有意义，即使它们本不应该是有意义的。现在，每当aNO_PAD指定排序规则。

(错误# 29322313)

当一个不是在或之间的不Predicate被计算为一个推入条件，零值没有被SQL标准中指定的条件消除。(错误# 29232744)

参考文献:参见Bug #28672214。

在内部,NDB对待零作为小于任何其他值，以及形式的谓词列<价值或列< =价值检查可能的空值。表单的谓词价值>列或价值> =列没有进行检查，这可能导致错误。现在，在这种情况下，这些谓词被重写，以便列出现在前面，以便它们也被检查是否存在零．(错误# 29231709)

参考文献:参见Bug #92407, Bug #28643463。

在MySQL优化器中实现了对常量的折叠之后，一个包含日期或DATETIME文字不能再被NDB．(错误# 29161281)

当连接条件在时态数据类型的列之间进行比较时，例如日期或DATETIME和相同类型的常量，如果条件以这种形式表示，则推入谓词列操作符常数，但当倒序时(如常数inverse_operator列)．(错误# 29058732)

当处理一个推入的条件时，NDB当比较的文字值在与之比较的数据类型的范围之外时，没有检测到抛出的错误或警告，从而被截断。这可能导致结果中行数过多或缺失。(错误# 29054626)

如果一个EQ_REF或裁判键的子项引用的是表的任何列，而不是推入连接的成员，则该表不是NDB表(因为它的格式是非本机的端序)，并且所联接的列的数据类型以端序敏感的格式存储，那么生成的键就会被生成，很可能导致返回一个(无效的)空联接结果。

因为只有大端序平台才能以非本机(小端序)格式存储表，所以这个问题只会出现在这样的平台上，尤其是SPARC，而不会出现在x86平台上。(错误# 29010641)

运行NDB 7.6及更高版本的API和数据节点不能使用较早版本系列中已解析的配置，因为在为较晚版本的新配置参数定义值方面过于严格，从而限制了可能的升级路径。现在，NDB 7.6和以后的版本对所有新参数在配置中显式指定不那么严格，在这种情况下使用硬编码的默认值。(错误# 28993400)

NDB 7.6连接到NDB 8.0集群时SQL节点挂起。(错误# 28985685)

中维护的模式分布数据NDB的二进制日志记录线程，该线程跟踪订阅程序的订阅程序的数量NDBSchema表总是为256个数据节点分配一些内存结构，而不管节点的实际数量。现在NDB只分配实际需要的这些结构。(错误# 28949523)

添加转储406（NdbfsDumpRequests)提供NDB节点日志中的全局检查点和本地检查点失速报告的文件系统信息。(错误# 28922609)

如果一个已连接的表因为不可推而被提前删除，那么在其他表的任何后续连接条件中都不能引用它，除非将这些条件从考虑中删除，即使这些条件本来是可推的。(错误# 28898811)

当启动或重新启动SQL节点并连接到集群时NDB已经开始,NDB报告错误4009集群故障因为它无法获得全局模式锁。这是因为MySQL Server作为初始化的一部分需要独占元数据锁，以便修改内部数据结构ndbcluster插件获得全局模式锁。如果连接到NDB还没有妥善设置mysqld初始化,mysqld收到来自的警告ndbcluster当后者无法获取全局模式锁，并将其打印到日志文件中，导致日志中出现意外错误时。当无法获取全局模式锁时，不向后台线程推送任何警告，并将NDB错误作为警告。(错误# 28898544)

之间的竞态条件DBACC而且DBLQH当同一行事务中的不同操作同时准备和中止时，就会发生内核块。这可能会导致DBTUP尝试在前一个操作已中止时准备一个操作，这是意外的，因此可能导致未定义的行为，包括潜在的数据节点故障。为了解决这个问题，DBACC而且DBLQH现在，在尝试准备操作之前，检查所有依赖项是否仍然有效。

(错误# 28893633)

数据节点在配置更改后重新启动，其结果是MaxNoOfTables，MaxNoOfOrderedIndexes,MaxNoOfUniqueHashIndexes在美国，它有时会出现一个误导性的错误信息，暗示这是一个临时错误和一个bug，但这两种情况都不是。

失败本身是意料之中的，因为至少有一个表对象的ID大于刚刚提到的参数的(新)和，并且该表无法恢复，因为允许的ID的最大值受该和的限制。错误消息已被更改以反映这一点，现在指示这是由于有问题的配置而导致的永久性错误。(错误# 28884880)

的ndbinfo.cpustat表报告了关于发送线程的不准确信息。(错误# 28884157)

当LCP状态为IDLE时，从主服务器执行LCP_COMPLETE_REP信号会导致断言。(错误# 28871889)

NDB现在提供动态.frm在发现在不支持MySQL数据字典的软件版本中创建的表时进行文件转换。以前，只有在MySQL服务器启动时的模式同步过程中，才支持对具有旧式元数据的表进行这样的转换，但随后就不支持了，这导致了错误NDB具有老式元数据的表，由ndb_restore以及其他类似的工具mysqld已启动，使用显示创建表或选择；这些表只有在重新启动后才可用mysqld．有了这个修复，就不再需要重新启动了。(错误# 28841009)

从早期版本升级到NDB 8.0版本的本地升级没有被删除.ndb尽管在NDB 8.0中不再使用这些文件。(错误# 28832816)

删除存储/ ndb /演示以及它从源树中包含的演示脚本和支持文件。这些都是过时的和未维护的，不能与任何当前版本的NDB集群一起工作。

也删除存储/ ndb / include / newtonapi，其中包括与NDB集群任何版本都不支持的过时且未维护的API相关的文件，以及其他地方对这些文件的引用。(错误# 28808766)

NDB 8.x没有版本兼容性表;这意味着运行NDB 8.0.13或7.6的API节点。x无法连接到运行NDB 8.0.14的数据节点。对于NDB API用户来说，这个问题表现为wait_until_ready ()．(错误# 28776365)

参考文献:参见Bug #18886034, Bug #18874849。

发出一个停止命令的ndb_mgm客户造成的ndbmtd最近添加到集群的进程在关闭阶段4时挂起。(错误# 28772867)

修复了以前的一个问题，禁止对查找类型使用推入条件(eq_ref)的操作。当时人们认为，不推入查找条件不会对性能产生任何可测量的影响，因为如果条件失败，只能删除单行。当时实现的解决方案没有考虑到这样一种可能性，即在推入连接中，查找操作可能是其他查找甚至扫描操作的父操作，这意味着消除单行实际上可能导致错误地消除整个分支。(错误# 28728603)

参考文献:这个问题是:Bug #27397802的回归。

当本地检查点(LCP)在除一个节点外的所有数据节点上完成，而该节点失败时，NDB没有继续完成LCP所需的步骤。这导致了以下问题:

没有新的LCPs可以启动。

重做和撤消日志没有被修剪，因此变得非常大，导致从磁盘恢复的时间增加。这导致了写服务失败，当重做日志的头和尾相遇时，最终导致集群关闭。这限制了集群的正常运行时间。

节点不再可能重新启动，因为数据节点重新启动需要节点的状态在磁盘上保持持久，然后节点才能在加入集群时提供冗余。对于具有两个数据节点和两个片段副本的集群，这意味着需要重新启动整个集群(系统重新启动)来修复问题(对于具有两个片段副本和四个或更多数据节点的集群，这是不必要的)。(Bug #28728485, Bug #28698831)

参考文献:参见Bug #11757421。

条件的可推性NDB是否限制了所有谓词都由一个逻辑连接和在一个特定的条件下必须是可以推动的NDB为了让整个条件被推入。在某些情况下，这严重限制了条件的可推性。此修复将条件分解为其组件，并计算每个谓词的可推性;如果某些谓词不能被推入，它们将作为剩余条件返回，MySQL服务器可以对其进行计算。(错误# 28728007)

运行分析表在一个NDB表的索引长度超过所支持的最大长度，将导致数据节点失败。(错误# 28714864)

在某些情况下，节点可能在初始重启期间挂起。(错误# 28698831)

参考文献:参见Bug #27622643。

当一个条件被推入存储引擎时，服务器会重新计算它，尽管在这种情况下只有匹配推入条件的行才会返回给服务器。(错误# 28672214)

在某些情况下，一个甚至多个数据节点在运行时意外关闭ndb_restore．当还原到数据节点数量与执行原始备份的集群不同的集群时，通常会发生这种情况，但并不总是限于此。

这个问题的根本原因是池的枯竭SafeCounter对象使用的DBDICT内核块作为执行模式事务的一部分，并从与协议共享的每个块实例池中取NDB事件设置和订阅处理。事件设置和订阅处理的并发性使得SafeCounter池可竭;事件和订阅处理可以处理池耗尽，但模式事务处理不能，这可能导致节点在恢复期间关闭。

这个问题可以通过给予来解决DBDICT模式事务使用独立的保留池SafeCounters不能被并发NDB活动活动。(错误# 28595915)

当备份由于缓冲区耗尽而中止时，在插入、更新和删除操作的触发器预期丢失之前的信号队列同步将导致中止信号在STOP_BACKUP阶段可能持续。中止将备份状态更改为ABORT_BACKUP_ORD，这导致数据节点在恢复后意外关闭STOP_BACKUP要求国家STOP_BACKUP_REQ．现在备份状态没有设置为STOP_BACKUP_REQ(请求备份继续)直到信号队列同步完成。(错误# 28563639)

的输出ndb_config——configinfo——xml——查询所有的配置更改ThreadConfig而且MaxNoOfExecutionThreads数据节点参数需要系统初始重启(最初重启= "系统" = " true ")．(错误# 28494286)

在由于错误而提交失败后，mysqld在试图使用表名时意外关闭。这是由于内部功能的问题ndbcluster_print_error ()．(错误# 28435082)

API节点应该观察到某个节点正在通过SL_STOPPING阶段(平稳停止)，并停止将节点用于新事务，这将最大限度地减少节点关闭过程后期阶段的潜在中断。API节点只能通过周期性的心跳信号得知节点状态的变化，因此可能无法避免与节点关闭进行交互。当心跳间隔较长时，会产生不必要的故障。现在，当一个数据节点被优雅地停止时，所有API节点都会直接收到通知，允许它们经历最小的中断。(错误# 28380808)

ndb_config——diff-default试图读取默认值为空字符串的参数时失败(＂＂)．(错误# 27972537)

ndb_restore在使用一个或多个staging表时，没有正确地恢复自动递增值。作为此修复的一部分，我们还在这种情况下阻止应用SYSTAB_0备份日志，它的内容继续直接基于表ID应用，它可以覆盖存储在SYSTAB_0不相关的表。(Bug #27917769, Bug #27831990)

参考文献:参见Bug #27832033。

ndb_restore使用了一种恢复自增量值的机制，这种机制不是原子的，因此在多个实例时可能会恢复不正确的自增量值ndb_restore是并行使用的。(错误# 27832033)

参考文献:参见Bug #27917769, Bug #27831990。

执行选择*从INFORMATION_SCHEMA。表导致SQL节点在某些情况下重新启动。(错误# 27613173)

当表团列被删除，然后用不同数量的团列中的用于监视表更改的事件定义在某些涉及通信错误的错误情况下可能不一致，因为没有执行相应事件的预期清除。特别是，当新版本的表有更多团列与原始表相比，一些事件可能丢失。(错误# 27072756)

查询内存耗尽时DBSPJ在为延迟操作存储相关id时，查询被中止，错误状态为20000查询因查询内存不足而中止．(错误# 26995027)

参考文献:参见Bug #86537。

当在非常高的负载下运行具有4个或更多数据节点的集群时，数据节点有时会出现错误899Rowid已经分配．(错误# 25960230)

mysqld当在服务器完全启动之前请求清除二进制日志时意外关闭，因此尚未准备好从ndb_binlog_index表格当这种情况发生时，请求任何必要的清除ndb_binlog_index表保存在队列中，等待服务器完全启动后执行。(错误# 25817834)

MaxBufferedEpochs在数据节点上使用，以避免由于滞后导致的行更改的过度缓冲NDB事件API用户;当来自一个或多个订阅者的纪元确认延迟此纪元数时，将触发异步断开连接，允许数据节点释放用于订阅的缓冲区空间。由于这种断开是异步的，它可能在数据节点上完成额外的新epoch之前没有完成，导致新的epoch无法捕获GCP完成记录，产生如下所示的警告:

[ndbd] ERROR——c_gcp_list.seize() failed... ... .[ndbd] WARNING—ACK wo/ gcp记录…

并导致以下警告:

断开节点%u，因为它已经超过MaxBufferedEpochs(100 > 100)，纪元....

此修复程序执行以下修改:

(错误# 20344149)

异步断开的mysqld会导致后续任何启动NDB API事务的尝试失败。如果在批量删除操作期间发生这种情况，则SQL层调用哈哈::end_bulk_delete ()，其实现方法为ha_ndbcluster假设事务已经启动，如果不是这样，可能会失败。通过在引用此方法使用的事务指针之前检查其是否已设置，可以解决此问题。(错误# 20116393)

删除编译时引发的警告NDB与叮当声6。(Bug #93634, Bug #29112560)

当在调试模式下执行重做日志时，数据节点在释放行时可能会失败。(Bug #93273, Bug #28955797)

一个NDB表中有两个外键NDB表的使用在级联删除一个或多个文本或团列泄漏内存。

作为修复的一部分，在级联删除是否不再支持打开外键NDB类时，子表包含的列使用团或文本类型。(Bug #89511, Bug #27484882)