重要变化：使用与原始群集中的数据节点ID恢复到群集时，ndb_restore尝试打开与节点ID 0对应的文件0.保持这种情况发生——nodeid和- Backupid.选项 - 既不在调用时明确地明确要求默认值ndb_restore。（bug＃28813708）

包装;MySQL NDB ClusterJ:libndbclient.在某些平台的构建中缺失。(错误# 28997603)

NDB磁盘数据:当一个日志文件组有超过18条撤消日志时，就不可能重新启动集群。(错误# 251155785)

参考:参见Bug #28922609。

NDB复制：一种删除数据库涉及某些非常大的表的操作可能会导致非计划内的集群关闭。(错误# 28855062)

NDB复制：当在主机上写入时，以多种变化影响团属于相同主键的列值是相同epoch的一部分-被复制到从节点，由于约束违反ndb $ blob_id_部分表格(错误# 28746560)

NDB集群api:当NDB内核SUMA块发送TE_ALTER事件，它不会跟踪事件的所有片段何时被发送。当NDB接收事件，缓冲片段，并在所有片段到达时处理事件。对于非常大的表定义，当传输和接收之间的时间可能跨越多个epoch时，可能会出现问题;在这段时间里,SUMA可以发送A.SUB_GCP_COMPLETE_REP信号，表明它已经发送了一个epoch的所有数据，即使在这种情况下这并不完全正确，因为可能有一个TE_ALTER事件仍等待发送数据节点。接待的SUB_GCP_COMPLETE_REP导致关闭该时代的缓冲区。因此，当TE_ALTER最后到达，NDB假设它是早期的时期的重复，默默地丢弃它。

我们通过确保的是解决问题SUMA内核块永远不会发送一个SUB_GCP_COMPLETE_REP对象中存在未发送片段的任何时期SUB_TABLE_DATA信号。

此问题可能对利用NDB API应用程序产生影响TE_ALTER事件。(SQL节点不使用任何TE_ALTER(Bug #28836474)

在配置变更后重新启动数据节点的情况下，其结果是减少的总和maxNooftables.那maxnooforderedindexes.,maxnoodunquashindexes.，它有时会失败，并出现一个误导性的错误消息，提示一个临时错误和一个bug，但两者都不是。

预计失败本身,因为至少有一个表格对象ID大于参数的(新)和刚刚提到的,和这个表不能恢复由于ID允许的最大价值是有限的。错误消息已被更改以反映这一点，现在表明这是由于问题配置造成的永久性错误。(错误# 28884880)

当本地检查点（LCP）在除其中除了除其中之外的所有数据节点上时，此节点都失败，NDB没有继续完成LCP所需的步骤。这导致了下列问题:

不可能启动新的lcp。

重做和撤消日志未修剪，因此过度增长，导致从磁盘恢复的时间增加。这导致写入服务失败，当重做日志的头部达到尾部时，最终导致集群关机。这对集群正常运行时间提出了限制。

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

参考:参见Bug #11757421。

跑步分析表在AN.NDB表具有比支持的最大长度长的索引导致数据节点失败。（bug＃28714864）

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

参考：另请参阅：Bug＃27622643。

输出ndb_config.- CONFIGINFO.——xml- query-all现在显示配置更改ThreadConfig和maxnofexecutionthreads.数据节点参数需要系统初始重启(重新启动=“系统”初始=“true”）。（bug＃28494286）

API节点应该注意到一个节点正在移动SL_STOPPING阶段（优雅停止）并停止使用节点进行新事务，从而最大限度地减少节点关闭过程的稍后阶段的潜在中断。API节点仅通过周期性心跳信号通知节点状态变化，因此可能无法避免与关闭节点的交互。当心跳间隔长时间产生这种不必要的故障。现在，当正常停止数据节点时，所有API节点都会直接通知，允许它们体验最小的中断。（bug＃28380808）

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

使用锤头扫描或ACC.扫描，或者当使用主键执行读操作时，可以启动对行的读操作并点击实时中断，在此期间需要等待页面在内存中可用。当页面请求稍后返回时，由于校验和无效，读取该行的尝试失败;这是因为，当行被删除时，其校验和将失效。

这个问题通过引入一个新的元组头来解决delete_wait.标志，在开始任何行扫描或PK读取操作之前选中，其中磁盘数据页面尚未可用，并且当最终提交行时清除。（bug＃27584165，bug＃93035，bug＃28868412）

当表团删除列，然后用不同数量的方式重新创建团当没有执行预期的相应事件清理时，用于监视表更改的事件定义可能在某些涉及通信错误的错误情况下变得不一致。特别是，当新版本的表有更多团列比原始表，可能缺少一些事件。（bug＃27072756）

在非常高的负载下运行具有4个或更多数据节点的集群时，数据节点有时会出现错误899Rowid已经分配。（bug＃25960230）

mysqld在服务器完全启动之前请求二进制日志的清除时意外关闭，因此尚未准备好删除来自的行ndb_binlog_index表格当这种情况发生时，请求任何需要的清除ndb_binlog_index表格保存在队列中并在服务器完全启动时保持执行。（bug＃25817834）

启动时，数据节点复制元数据，而本地检查点更新元数据。为了避免任何冲突，在复制元数据时，任何正在进行的LCP活动都会暂停。当一个本地检查点在一个给定节点上暂停，而另一个节点也正在重新启动检查该节点上的完整LCP时，出现了一个问题;检查实际上导致LCP在元数据复制完成之前完成，因此提前结束了暂停。现在，在这种情况下，LCP完成检查将等待一个暂停的LCP完成，直到元数据复制完成，并且在它开始的LCP中，暂停如预期的那样结束。(错误# 24827685)

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

NdbScanFilter并不总是处理零根据SQL标准，可能导致MySQL Server发送要过滤（否则不需要的不合格行。（bug＃92407，bug＃28643463）

参考文献：另见：bug＃93977，bug＃29231709。

NDB试图使用大于()的条件下推>)及少于(<)比较枚举列值，但这可能导致结果省略了行。现在这种比较不再被推到。平等的比较（=）和不平等（<>/！=),枚举值不受此变化的影响，并且仍可按下包括这些比较的条件。（bug＃92321，bug＃28610217）