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

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

参考:参见Bug #28922609。

NDB集群API：当。。。的时候NDB.内核的SUMA.块发送Te_alter.事件，它不会跟踪发送事件的所有碎片时。什么时候NDB.收到事件，它会缓冲片段，并在所有片段到达时处理事件。对于非常大的表定义，可能出现问题，当传输和接收之间的时间可能跨越多个时期时;在这段时间，SUMA.可以发送一个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,MaxNoOfUniqueHashIndexes，它有时失败，误导错误消息，这表明临时错误和错误，既不是这种情况。

预期故障本身是由于至少有一个具有id的表对象大于刚才提到的参数的（新）的（新）的总和，并且由于允许的ID的最大值，因此无法恢复此表受到这笔款项的限制。错误消息已更改为反映此操作，现在表示由于问题配置而导致的永久错误。（bug＃28884880）

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

不可能启动新的lcp。

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

由于数据节点重新启动所要求在加入群集时可以提供冗余，因此不再可能重新启动节点。对于具有两个数据节点和两个片段副本的群集，这意味着需要重新启动整个群集（系统重启）来解决问题（这对于具有两个片段副本和四个或更多数据节点的群集而言，这不是必需的）。（bug＃28728485，bug＃28698831）

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

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

在初始重启期间，在某些情况下可以在某些情况下挂起。（bug＃28698831）

参考:参见Bug #27622643。

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

API节点应该观察到节点正在移动SL_STOPPING阶段(优雅停止)和停止对新事务使用节点，这将最小化节点关闭进程后期阶段的潜在中断。API节点只能通过定期的心跳信号获知节点状态的变化，因此可能无法避免与节点关闭进行交互。当心跳间隔很长时，这会产生不必要的故障。现在，当一个数据节点被优雅地停止时，所有API节点将被直接通知，从而使它们受到的破坏最小。(错误# 28380808)

执行选择*从Information_schema.Tables.导致SQL节点在某些情况下重新启动。（bug＃27613173）

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

通过引入新的元组标题来解决这个问题DELETE_WAIT标记，在对磁盘数据页尚未可用的行开始任何行扫描或PK读操作之前检查，并在最终提交该行时清除该行。(Bug #27584165, Bug #93035, Bug #28868412)

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

在非常高负载下与4个或更多数据节点运行群集时，数据节点可能会失败，错误899Rowid已经分配了。(错误# 25960230)

mysqld.当在服务器完全启动之前请求清除二进制日志，因此它还没有准备好从ndb_binlog_index.表格当这种情况发生时，请求任何需要的清除ndb_binlog_index.表保存在队列中，并在服务器完全启动时保存以供执行。(错误# 25817834)

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

异步断开的mysqld.从群集中导致任何后续尝试启动NDB API事务失败。如果发生在批量删除操作期间，则调用SQL图层哈哈::end_bulk_delete ()，其实现方式为ha_ndbcluster.假设事务已启动，如果不是这种情况，可能会失败。通过检查此方法使用的事务指针在引用它之前设置了此问题，修复了此问题。（bug＃20116393）

ndbscanfilter并不总是处理零根据SQL标准，这可能会导致发送不符合条件的行，由MySQL服务器进行过滤(否则不需要)。(Bug #92407, Bug #28643463)

参考:参见Bug #93977, Bug #29231709。

NDB.尝试使用大于（>)及少于(<）比较枚举列值，但这可能导致结果中省略行。现在，这种比较不再被压低。相等比较(=)和不平等(<>/! =),枚举值不受此更改的影响，并且包括这些比较在内的条件仍然可以下推。(Bug #92321, Bug #28610217)