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

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

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

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

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

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

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）

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

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

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

无法启动新的 LCP。

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

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

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

在索引长度超过支持的最大长度ANALYZE TABLE的 表上 运行会导致数据节点失败。NDB（漏洞#28714864）

在某些情况下，节点可能会在初始重启期间挂起。（缺陷号 28698831）

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

ndb_config 的输出现在显示 和 数据节点参数的配置更改需要系统初始重启 ( )。（漏洞#28494286）--configinfo --xml --query-allThreadConfigMaxNoOfExecutionThreadsrestart="system" initial="true"

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

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

当使用TUPscan 或 ACCscan 扫描一行时，或者使用主键执行读取时，有可能开始读取该行并命中实时中断，在此期间需要等待页面变为可用在记忆中。当页面请求稍后返回时，由于校验和无效，尝试读取该行失败；这是因为，删除该行时，其校验和将失效。

这个问题通过引入一个新的元组标头 DELETE_WAIT标志来解决，该标志在对磁盘数据页尚不可用的行开始任何行扫描或 PK 读取操作之前进行检查，并在该行最终提交时清除。（错误#27584165、错误#93035、错误#28868412）

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

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

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

启动时，数据节点复制元数据，而本地检查点更新元数据。为避免任何冲突，在复制元数据时暂停任何正在进行的 LCP 活动。当本地检查点在给定节点上暂停时出现问题，并且另一个节点也在重新启动检查该节点上的完整 LCP；检查实际上导致 LCP 在元数据复制完成之前完成，因此过早地结束了暂停。现在在这种情况下，LCP 完成检查会等待完成暂停的 LCP，直到元数据复制完成并且暂停按预期结束，在它开始的 LCP 内。（漏洞 #24827685）

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

NdbScanFilter并不总是 NULL根据 SQL 标准处理，这可能导致发送不合格的行以被 MySQL 服务器过滤（否则不需要）。（缺陷 #92407，缺陷 #28643463）

参考资料：另请参阅：Bug #93977、Bug #29231709。

NDB尝试在大于 ( >) 和小于 ( <) 与 ENUM列值的比较中使用条件下推，但这可能会导致结果中省略行。现在这样的比较不再被推倒了。相等 ( =) 和不等 ( <>/ !=) 与 ENUM值的比较不受此更改的影响，包括这些比较的条件仍然可以下推。（缺陷 #92321，缺陷 #28610217）