不兼容的更改： 在 NDB 7.6 及更早版本中实现的连接到 NDB Cluster 的 MySQL 服务器之间的权限分配在 NDB 8.0 中不起作用，并且大多数支持这些的代码现在已被删除。当mysqld在中检测到此类表时 NDB，它会使用InnoDB存储引擎在其本地创建影子表；这些影子表是在连接到 NDB 集群的每个 MySQL 服务器上创建的。使用存储引擎的权限表 NDB不用于访问控制；升级所有连接的 MySQL 服务器后，NDB可以使用ndb_drop_table安全地删除中的特权表。

出于兼容性原因，ndb_restore --restore-privilege-tables 仍可用于将从 NDB Cluster 的先前版本获取的备份中存在的分布式特权表还原到运行 NDB 8.0 的集群。这些表的处理方式如前一段所述。

有关从以前的 NDB Cluster 版本系列升级到 NDB 8.0 的其他信息，请参阅 升级和降级 NDB Cluster。

不兼容的更改： 为了与 保持一致未指定子句，或者指定的关键字没有InnoDB， NDB存储引擎现在使用生成的约束名称。在以前 版本中，使用该 值。 CONSTRAINT symbolCONSTRAINTsymbolNDBNDBFOREIGN KEY index_name

上述更改可能会导致依赖于以前的外键约束命名行为的应用程序不兼容。（漏洞#29173134）

打包： 可从 https://hub.docker.com/r/mysql/mysql-cluster/获取此版本的 Docker 镜像。（缺陷 #96084，缺陷 #30010921）

事务协调器中的资源分配（请参阅 DBTC 块）现在使用动态内存池执行。这意味着由数据节点配置参数（如 事务参数和 事务临时存储中讨论的参数）确定的资源分配现在受到限制，以免超过事务协调器可用的总资源。

作为这项工作的一部分，DBTC还添加了几个新的数据节点参数来控制此处列出的事务资源。有关这些新参数的更多信息，请参阅 事务资源分配参数。（错误#29164271，错误#29194843）

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

NDB现在可以使用多个本地数据管理器 (LDM) 在单个数据节点上以并行方式执行备份。（以前，备份是跨数据节点并行完成的，但在数据节点进程中始终是串行的。） ndb_mgmSTART BACKUP客户端中的命令 不需要特殊语法 来启用此功能，但所有数据节点必须使用多个 LDM。这意味着数据节点必须运行ndbmtd，并且必须将它们配置为在进行备份之前使用多个 LDM（请参阅 多线程配置参数 (ndbmtd)）。

此版本中引入的 EnableMultithreadedBackup 数据节点参数默认启用（设置为 1）。[ndbd default]您可以通过在所有数据节点上或在集群的全局配置文件 ( config.ini) 部分将此参数设置为 0 来禁用多线程备份并强制创建单线程备份。

ndb_restore现在还检测多线程备份并自动尝试并行恢复它。通过稍微修改通常的恢复过程，也可以恢复与以前版本的 NDB Cluster 并行进行的备份。

有关获取和恢复使用数据节点上的并行性创建的 NDB Cluster 备份的更多信息，请参阅使用并行数据节点获取 NDB 备份和从并行获取的备份中恢复。（错误#28563639，错误#28993400）

源代码分发中包含的编译集群脚本NDB不再支持源内构建。

源代码分发 中包含的编译集群脚本现在支持 使用CMake3构建。NDB

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

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

条件下推不再局限于谓词项引用条件被推送到的同一个表中的列值；现在也可以从推送条件中引用查询计划中早期表中的列值。这让数据节点过滤出更多的行（并行），留下更少的工作由单个 mysqld进程执行，这有望显着提高查询性能。

有关详细信息，请参阅 发动机状况下推优化。

重要变更；NDB 磁盘数据： mysqldump在尝试转储NDB磁盘数据表时意外终止。其根本原因是mysqldumpEXTRA期望在表的列中 找到与撤消日志缓冲区相关的 INFORMATION_SCHEMA.FILES但此信息已在 NDB 8.0.13 中删除。此信息现在已恢复到EXTRA 列中。（漏洞 #28800252）

重要更改： 当使用与原始集群中的数据节点 ID 不同的数据节点 ID 恢复到集群时， ndb_restore 尝试打开与节点 ID 0 对应的文件。为了防止这种情况发生，--nodeid 和--backupid 选项——它们都没有默认值——是现在在调用 ndb_restore时明确需要两者。（漏洞#28813708）

重要变化： 从这个版本开始， ndb_log_bin系统变量的默认值现在是FALSE。（漏洞 #27135706）

打包; MySQL NDB ClusterJ： libndbclient在某些平台上的构建中缺失。（漏洞#28997603）

NDB Disk Data： 当一个日志文件组有超过 18 个撤销日志时，无法重新启动集群。（漏洞#251155785）

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

NDB 磁盘数据：使用表空间的 并发CREATE TABLE 语句导致元数据锁之间出现死锁。当 Ndb_metadata_change_monitor在检测到元数据更改后获取表空间和日志文件组上的独占元数据锁时会发生这种情况，因为每个独占元数据锁依次获取全局模式锁。此修复程序试图通过将由 Ndb_metadata_change_monitorto MDL_SHARED_READ。（漏洞 #29175268）

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

NDB 磁盘数据：MaxNoOfOpenFiles改进了与 验证时返回的错误消息， InitialNoOfOpenFiles 以使用户更清楚问题的性质。（漏洞#28943749）

NDB 磁盘数据：如果引用的表空间或日志文件组在其数据字典中不存在，则参与者 MySQL 服务器上ALTER TABLESPACE和 的模式分布ALTER LOGFILE GROUP现在在这种情况下，无论 MySQL 服务器之间有任何初始不匹配，语句的效果都会成功分发。（漏洞#28866336）

NDB Disk Data：针对同一个表空间 重复执行 ALTER TABLESPACE ... ADD DATAFILE导致数据节点挂起并离开，手动杀死后无法重启。（漏洞 #22605467）

NDB 复制：涉及某些非常大的表 的DROP DATABASE操作可能会导致集群意外关闭。（漏洞 #28855062）

NDB 复制： 当在 master 上写入时——以影响BLOB属于同一主键的列值的多个更改是同一时期的一部分的方式完成——被复制到 slave 时，由于 表中的约束违规而发生错误 1022。（缺陷号 28746560）NDB$BLOB_id_part

NDB Cluster API： NDB现在识别不需要减少锁争用的短期事务，并且 NdbBlob::close()在解锁仅导致额外工作和往返之前执行的情况下（例如启用自动提交时）不再调用此方法提交或中止事务。（漏洞 #29305592）

参考资料：另请参阅：Bug #49190、Bug #11757181。

NDB Cluster APIs： 当最近失败的操作被释放时，指向它的指针 NdbTransaction变得无效，并且在访问时导致 NDB API 应用程序失败。（漏洞#29275244）

NDB Cluster APIs： 当NDB内核的SUMA 块发送一个TE_ALTER事件时，它不会跟踪事件的所有片段何时发送。当 NDB接收到事件时，它会缓冲片段，并在所有片段都到达时处理事件。当传输和接收之间的时间可能跨越多个时期时，对于非常大的表定义可能会出现问题；在此期间， SUMA可以发送一个 SUB_GCP_COMPLETE_REP信号以指示它已发送一个纪元的所有数据，即使在这种情况下并非完全正确，因为可能 TE_ALTER仍有事件片段等待数据节点发送。接待处 SUB_GCP_COMPLETE_REP导致关闭该时期的缓冲区。因此，当TE_ALTER 最终到达时，NDB 假定它是较早时期的副本，并默默地丢弃它。

我们通过确保 SUMA内核块永远不会 SUB_GCP_COMPLETE_REP为任何有未发送的 SUB_TABLE_DATA信号片段的时期发送 a 来解决这个问题。

此问题可能会影响使用TE_ALTER事件的 NDB API 应用程序。（SQL 节点不使用任何TE_ALTER事件，因此它们和使用它们的应用程序不受影响。）（缺陷 #28836474）

当在DBSPJ 块中执行的推送连接必须在查询执行期间存储相关 ID 时，会在整个查询执行的生命周期内为这些分配内存，即使仅在生成结果集中的最新批次时才需要这些特定的相关 ID . 后续批次需要存储和分配额外的相关 ID；因此，如果查询花费了足够长的时间才能完成，则会导致查询内存耗尽（错误 20008）。现在在这种情况下，内存仅在当前结果批次的生命周期内分配，并在批次完成后释放并可供重新使用。（缺陷号 29336777）

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

当比较或散列使用 NO_PAD排序规则的固定长度字符串时，任何尾随填充字符（通常是空格）都会被发送到散列和比较函数，使它们变得重要，即使它们不应该如此。NO_PAD现在，无论何时指定排序规则， 都会从固定长度的字符串中删除任何此类尾随空格 。

（漏洞 #29322313）

当NOT INorNOT BETWEEN谓词被评估为推送条件时， NULL值不会被 SQL 标准中指定的条件消除。（漏洞#29232744）

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

在内部，NDB视为 NULL小于任何其他值，并 检查or 形式的谓词是否存在可能的空值。or 形式的谓词 未被检查，这可能导致错误。现在在这种情况下，这些谓词被重写，以便列首先出现，这样它们也会被检查是否存在. （漏洞 #29231709）column < valuecolumn <= valuevalue > columnvalue >= columnNULL

参考资料：另请参阅：Bug #92407、Bug #28643463。

在 MySQL 优化器中实现了常量折叠后，包含 DATEor DATETIME文字的条件不能再被下推NDB。（漏洞 #29161281）

当连接条件在时间数据类型（例如DATE or ）的列DATETIME与相同类型的常量之间进行比较时，如果条件以 form 表示，则谓词被推送，但在倒置顺序（如）中则不会。（缺陷号 29058732）column operator constantconstant inverse_operator column

处理推送条件时，NDB未检测到当被比较的文字值超出与之比较的数据类型范围并因此被截断时引发的错误或警告。这可能会导致结果中的行过多或缺失。（漏洞 #29054626）

如果推送连接的子项中的EQ_REFor REF键引用了不是推送连接成员的表的任何列，则该表不是NDB 表（因为它的格式是非本机字节顺序），并且该列的数据类型是joined on 以字节序敏感的格式存储，然后生成生成的密钥，可能导致返回（无效的）空连接结果。

由于只有大端平台可以以非本机（小端）格式存储表，因此预计只会在此类平台（尤其是 SPARC）上出现此问题，而不是在 x86 平台上。（错误号 29010641）

运行 NDB 7.6 及更高版本的 API 和数据节点无法使用早期版本系列中的现有解析配置，因为在为更高版本的新配置参数定义值方面过于严格，这限制了可能的升级路径。现在 NDB 7.6 及更高版本对于在它们所服务的配置中明确指定所有新参数的要求不那么严格，并且在这种情况下使用硬编码默认值。（缺陷号 28993400）

NDB 7.6 SQL 节点在尝试连接到 NDB 8.0 集群时挂起。（缺陷号 28985685）

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

添加DUMP 406 ( NdbfsDumpRequests) 以向 NDB节点日志中的全局检查点和本地检查点停止报告提供文件系统信息。（漏洞 #28922609）

当一个连接表因为不可推送而被提前消除时，如果不从考虑中消除这些条件，即使这些条件是可推送的，也不能在其他表的任何后续连接条件中引用它。（漏洞#28898811）

启动或重启SQL节点，连接到NDB已经启动 的集群时，由于无法获取全局模式锁，NDB报错4009 Cluster Failure 。这是因为作为初始化一部分的 MySQL 服务器获取独占元数据锁以修改内部数据结构，而 ndbcluster插件获取全局模式锁。如果在mysqld初始化 NDB期间尚未正确建立连接， mysqld会收到来自 ndbcluster后者在获取全局模式锁失败时，打印到日志文件，导致日志出现意外错误。这是通过在发生获取全局模式锁失败时不向后台线程推送任何警告并将NDB错误作为警告推送来解决的。（漏洞#28898544）

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

（缺陷号 28893633）

如果数据节点在配置更改后重新启动，其结果是、 和 的总和减少 MaxNoOfTables， 它有时会失败并出现误导性错误消息，提示临时错误和错误，但两者都不是这种情况。 MaxNoOfOrderedIndexesMaxNoOfUniqueHashIndexes

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

该ndbinfo.cpustat表报告了有关发送线程的不准确信息。（漏洞#28884157）

在 LCP 状态为 IDLE 时执行来自主机的 LCP_COMPLETE_REP 信号会导致断言。（漏洞#28871889）

NDB.frm现在在发现在不支持 MySQL 数据字典的软件版本中创建的表期间提供即时 文件翻译。以前，只有在 MySQL 服务器启动期间的模式同步期间才支持对具有旧式元数据的表进行这种翻译，但随后不支持，这导致在mysqld之后由ndb_restore和其他此类工具 NDB 创建的具有旧式元数据的表 出现错误开始，使用 或 访问；这些表仅在重新启动mysqld后可用。通过此修复，不再需要重新启动。（漏洞 #28841009）SHOW CREATE TABLESELECT

从早期版本就地升级到 NDB 8.0 版本不会删除.ndb文件，即使这些文件不再用于 NDB 8.0。（漏洞#28832816）

从源代码树中删除storage/ndb/demos了它包含的演示脚本和支持文件。这些已过时且未维护，并且不适用于任何当前版本的 NDB Cluster。

还删除了storage/ndb/include/newtonapi，其中包括与 NDB Cluster 的任何版本都不支持的过时和未维护的 API 相关的文件，以及对这些文件的其他引用。（漏洞#28808766）

NDB 8.x 没有版本兼容性表；这意味着运行 NDB 8.0.13 或 7.6.x 的 API 节点无法连接到运行 NDB 8.0.14 的数据节点。对于 NDB API 用户，此问题本身表现为 wait_until_ready(). （缺陷号 28776365）

参考资料：另请参阅：Bug #18886034、Bug #18874849。

在ndb_mgm客户端中 发出STOP命令导致 最近添加到集群的ndbmtd进程在关闭期间在第 4 阶段挂起。（漏洞#28772867）

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

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

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

无法启动新的 LCP。

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

节点重启不再可能，因为数据节点重启需要节点的状态在磁盘上持久化，然后才能在加入集群时提供冗余。对于具有两个数据节点和两个分片副本的集群，这意味着需要重新启动整个集群（系统重启）才能解决此问题（对于具有两个分片副本和四个或更多数据节点的集群来说，这不是必需的） . （错误#28728485，错误#28698831）

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

条件的可推送性 受到限制，因为给定条件内NDB由逻辑连接的所有谓词都必须是可推送的，以便推送整个条件。在某些情况下，这严重限制了条件的可推送性。此修复将条件分解为其组件，并评估每个谓词的可推送性；如果无法推送某些谓词，则将它们作为可由 MySQL 服务器评估的余数条件返回。（漏洞 #28728007）ANDNDB

在索引长度超过支持的最大长度ANALYZE TABLE的 表上 运行会导致数据节点失败。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 的输出现在显示 和 数据节点参数的配置更改需要系统初始重启 ( )。（漏洞#28494286）--configinfo --xml --query-allThreadConfigMaxNoOfExecutionThreadsrestart="system" initial="true"

由于错误导致提交失败后，mysqld 在尝试获取所涉及的表的名称时意外关闭。这是由于内部功能的问题 ndbcluster_print_error()。（漏洞 #28435082）

API 节点应观察到节点正在经历 SL_STOPPING阶段（正常停止）并停止使用该节点进行新交易，从而最大限度地减少节点关闭过程后期阶段的潜在中断。API 节点仅通过周期性心跳信号获知节点状态变化，因此可能无法避免与节点关闭交互。当心跳间隔很长时，这会产生不必要的故障。现在，当一个数据节点被优雅地停止时，所有 API 节点都会被直接通知，让它们经历最小的中断。（缺陷号 28380808）

--diff-default尝试读取默认值为空字符串 ("")的参数时， ndb_config失败。（漏洞#27972537）

当使用一个或多个登台表时， ndb_restore未正确恢复自动增量值。作为此修复的一部分，我们还在这种情况下阻止应用 SYSTAB_0备份日志，其内容继续直接根据表 ID 应用，这可能会覆盖存储在 SYSTAB_0不相关表中的自动增量值。（错误#27917769，错误#27831990）

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

ndb_restore采用了一种恢复非原子自动增量值的机制，因此当并行使用多个ndb_restore实例时，可能会产生不正确的自动增量值。（漏洞 #27832033）

参考资料：另请参阅：Bug #27917769、Bug #27831990。

在某些情况下，执行会导致 SQL 节点重新启动。（漏洞#27613173）SELECT * FROM INFORMATION_SCHEMA.TABLES

当包含BLOB列的表被删除然后使用不同数量的 BLOB列重新创建时，当未执行相应事件的预期清理时，在涉及通信错误的某些错误情况下，用于监视表更改的事件定义可能会变得不一致。特别是，当新版本的表 BLOB比原来的表有更多的列时，一些事件可能会丢失。（漏洞#27072756）

DBSPJ 当为延迟操作存储相关 ID 时内核块 中的查询内存耗尽时，查询被中止，错误状态为 20000 Query aborted due to out of query memory。（漏洞#26995027）

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

在非常高的负载下运行具有 4 个或更多数据节点的集群时，数据节点有时会失败并显示错误 899 Rowid already allocated。（缺陷号 25960230）

在服务器完全启动之前请求清除二进制日志时， mysqld意外关闭，因此它还没有准备好从 ndb_binlog_index表中删除行。现在，当发生这种情况时，任何需要的表清除请求都会 ndb_binlog_index保存在队列中，并在服务器完全启动后等待执行。（缺陷号 25817834）

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

    [ndbd] ERROR    -- c_gcp_list.seize() failed...

    ...

    [ndbd] WARNING  -- ACK wo/ gcp record...

并导致以下警告：

    Disconnecting node %u because it has exceeded MaxBufferedEpochs
    (100 > 100), epoch ....

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

（缺陷号 20344149）

mysqld与集群 的异步断开导致任何后续启动 NDB API 事务的尝试失败。如果这发生在批量删除操作期间，名为 的 SQL 层 HA::end_bulk_delete()，其实现ha_ndbcluster假定事务已启动，如果不是这种情况，则可能会失败。通过在引用此方法之前检查是否设置了此方法使用的事务指针来解决此问题。（缺陷号 20116393）

删除了 NDB使用 Clang 6 编译时引发的警告。（错误 #93634，错误 #29112560）

在调试模式下执行重做日志时，数据节点可能会在取消分配行时失败。（缺陷 #93273，缺陷 #28955797）

一个表在另一个表NDB上同时使用外键和一个或多个 或 列泄漏内存。 NDBON DELETE CASCADETEXTBLOB

作为此修复的一部分， 当子表包含使用任何或类型的列时，表ON DELETE CASCADE上的外键不再受支持。（漏洞 #89511，漏洞 #27484882）NDBBLOBTEXT