NDB集群api:当事务从集群连接启动时，表格而且指数Schema对象可以传递给这个事务使用。如果从不同的连接获取了这些模式对象(Ndb_cluster_connection对象)，可以通过删除或断开所属连接在任何位置删除它们。这可能会使连接保留无效的模式对象，从而导致NDB API应用程序在解引用这些对象时失败。

方法可避免此问题，如果应用程序使用多个连接，那么现在可以设置一个检查，以便在向事务传递模式对象时检测连接之间的模式对象共享NdbTransaction: setSchemaObjectOwnerChecks ()方法中添加的。当启用此检查时，将从连接获取具有相同名称的模式对象，并将其与传递给事务的模式对象进行比较。匹配失败将导致应用程序失败并出现错误。(错误# 19785977)

NDB集群api:默认hashmap桶数量的增加(DefaultHashMapSizeAPI节点配置参数)从240到3480在MySQL NDB集群7.2.11增加了内部的大小DictHashMapInfo: HashMap类型。该类型在某些类型的堆栈上分配可以获得的()调用，这可能导致NDB API用户的堆栈溢出问题。

为了避免这个问题，现在从堆动态分配哈希映射。(错误# 19306793)

当MySQL NDB集群从NDB 7.3升级到NDB 7.4时，第一个以NDB 7.4数据节点二进制启动的数据节点导致主节点(仍然运行NDB 7.3)失败，出现2301错误，然后在启动阶段5期间自身失败。(错误# 20608889)

NDB事件缓冲区分配中的内存泄漏导致每个纪元都会泄漏一个事件。(由于一个SQL节点使用3个事件缓冲区，每个SQL节点每个epoch泄露3个事件。)这意味着MySQL NDB集群mysqld泄漏的内存量与的大小成反比TimeBetweenEpochs也就是说，该参数的值越小，单位时间内泄漏的内存量就越大。(错误# 20539452)

的值Ndb_last_commit_epoch_server而且Ndb_last_commit_epoch_session某些平台的状态变量报告错误。为了纠正这个问题，这些值现在在内部存储为很久很久,而不是长．(错误# 20372169)

从备份中恢复MySQL NDB集群时，在恢复另一个节点时重启的失败节点无响应，导致ndb_restore失败并退出。(错误# 20069066)

当一个数据节点发生故障或正在重新启动时，同一节点组中的其他节点将向订阅者重新发送它们认为故障节点尚未发送的任何数据。通常，当数据节点(实际上是SUMA内核块)发送所有属于它负责的epoch的数据时，它发送一个SUB_GCP_COMPLETE_REP向所有订阅者发送信号，其中每个订阅者都响应一个SUB_GCP_COMPLETE_ACK．当SUMA从所有订阅者处接收此确认，它将此消息报告给同一节点组中的其他节点，以便它们知道在后续节点故障时不需要重新发送此数据。如果一个节点在所有订阅者发送此确认之前失败，但在同一节点组中的所有其他节点从失败节点接收到此确认之前失败，则可能两次发送(并报告为完成)某些时期的数据，这可能导致计划外的关闭。

对该问题的修复增加了报告的计数SUB_GCP_COMPLETE_ACK一个标识符列表，接收端可以使用它来跟踪哪些桶已经完成，并忽略已经完成的桶的任何重复报告。(错误# 17579998)

的ndbinfo.restart_info表中没有如预期的那样在节点重新启动后包含新行。(Bug #75825, Bug #20504971)

的输出格式显示创建表对于一个NDB包含外键约束的表与等价的表不匹配InnoDB表，这可能导致一些第三方应用程序的问题。(Bug #75515, Bug #20364309)

一个ALTER TABLE控件上包含注释和分区选项的NDB表导致执行它的SQL节点失败。(Bug #74022, Bug #19667566)