重要变化： 以前，NDB调度程序总是以预定的方式针对吞吐量优化速度（这是硬编码的）；现在可以使用 SchedulerResponsiveness 数据节点配置参数来设置此余额。此参数接受 0-10 范围内的整数，默认值为 5。较高的值提供相对于吞吐量的更好的响应时间。较低的值提供更高的吞吐量，但会增加响应时间。（错误#78531，错误#21889312）

tc_time_track_stats 将表格 添加到ndbinfo信息数据库中。此表提供与事务、关键操作和由 执行的扫描操作相关的时间跟踪信息 NDB。（错误#78533，错误#21889652）

重要更改： MySQL NDB Cluster 7.3.11 和 MySQL NDB Cluster 7.4.8 中的修复导致ndb_restore执行唯一键检查，即使在不恢复数据的模式下运行时，例如使用程序的 --restore-epochor --print-data选项时。

这种行为上的改变导致现有的有效备份例程失败；为避免此问题影响此版本和未来版本，已恢复之前的修复。这意味着在那些版本中添加的运行 ndb_restore --disable-indexes或 --rebuild-indexes在包含唯一索引的表上使用时的要求也被取消了。（缺陷号 22345748）

参考资料：另请参阅：Bug #22329365。恢复补丁：Bug #57782，Bug #11764893。

重要更改： 用户现在可以使用此版本中为程序引入和 NDB程序 对于 ndb_mgm， 取代现有选项。（错误#57576，错误#11764714​​）--connect-retries--connect-retry-delay--connect-retries--try-reconnect

NDB 磁盘数据：表 的列上的唯一索引 NDB是通过关联的内部有序索引实现的，用于扫描。在删除索引时，首先删除此有序索引，然后删除唯一索引本身。这意味着，当删除由于（例如）违反约束而被拒绝时，该语句被拒绝但关联的有序索引仍然被删除，因此任何对该表使用扫描的后续操作都会失败。我们通过在删除有序索引之前先删除唯一索引来解决这个问题；当删除唯一索引失败时，不再执行相关有序索引的删除。（错误#78306，错误#21777589）

NDB Cluster API： 二进制日志注入器无法正确 TE_INCONSISTENT处理 Ndb::nextEvent(). （漏洞 #22135541）

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

NDB Cluster API： Ndb::pollEvents()并且 pollEvents2()接收事件的速度很慢，依赖于其他客户端线程或块来代表它们执行传输器的轮询。此修复程序允许客户端线程在必须等待这些方法之一时执行其自己的传输器轮询。

传输器轮询的引入还揭示了 ndbcluster_binlog处理程序中缺少互斥锁保护的问题，该问题已作为此修复的一部分添加。（错误#79311、错误#20957068、错误#22224571）

NDB Cluster API： 垃圾收集是在 的实现中对几个对象执行的 NdbEventOperation，基于这些 GCI 已被客户端使用，包括那些已被删除的 Ndb::dropEventOperation()。在此实现中，假设全局检查点索引 (GCI) 始终单调递增，尽管在重置 GCI 的初始重启期间情况并非如此。这可能导致 NDB API 中的事件对象过早释放或根本不释放，在后一种情况下会导致资源泄漏。

为了防止这种情况发生，NDB 事件对象的实现现在在内部跟踪 GCI 和 GCI 的生成；每当节点进程重新启动时，世代就会增加，并且该值现在用于提供单调递增的序列。（错误#73781，错误#21809959）

在调试版本中，WAIT_EVENTwhile 轮询导致过多的日志记录到标准输出。（漏洞 #22203672）

当 CREATE TABLE在具有多个 SQL 节点的 MySQL NDB Cluster 上执行模式操作时，执行操作的 SQL 节点可能会在等待其他节点的确认时超时。当不同的 SQL 节点对 、 或其他影响二进制日志记录的 mysqld 选项有不同的设置时，可能 --ndb-log-updated-only会 --ndb-log-update-as-write发生这种情况NDB。

发生这种情况是因为，为了在它们之间分发模式更改，所有 SQL 节点都订阅系统表中的更改，并且所有 SQL 节点都通过订阅和 事件ndb_schema了解彼此的订阅。要订阅的事件的名称是根据表名构造的，添加 或作为前缀。TE_SUBSCRIBETE_UNSUBSCRIBEREPL$REPLF$REPLF$当为表指定完整的二进制日志记录时使用。前面描述的问题的出现是因为提到的选项的不同值可能导致不同的 SQL 节点订阅不同的事件，这意味着所有 SQL 节点不一定相互了解，因此处理等待模式分发完成的代码没有按设计工作。

为了解决这个问题，MySQL NDB Cluster 现在将该 ndb_schema表视为一种特殊情况，并始终对该表强制执行完整的二进制日志记录，而与mysqld二进制日志记录选项的任何设置无关。（错误#22174287，错误#79188）

NDB当这些列 BIT定义 为COLUMN_FORMAT DYNAMIC. （缺陷号 21889267）

创建具有最大支持列数 (512) 的表全部使用COLUMN_FORMAT DYNAMIC会导致数据节点故障。（缺陷号 21863798）

在某些情况下，集群故障（错误 4009）被报告为 Unknown error code。（缺陷号 21837074）

对于GET_TABINFOREQ执行CREATE INDEX 语句时的超时，mysqld 返回错误 4243（未找到索引）而不是预期的错误 4008（从 NDB 接收失败）。

此错误的修复还修复了 DBDICT作为 DDL 操作的一部分发送到内核块的许多其他信号的类似超时问题，包括ALTER_TAB_REQ, CREATE_INDX_REQ, DROP_FK_REQ, DROP_INDX_REQ, INDEX_STAT_REQ, DROP_FILE_REQ, CREATE_FILEGROUP_REQ, DROP_FILEGROUP_REQ, CREATE_EVENT, WAIT_GCP_REQ, DROP_TAB_REQ和 LIST_TABLES_REQ，以及在处理NDB 模式操作。（缺陷号 21277472）

参考资料：另请参阅：Bug #20617891、Bug #20368354、Bug #19821115。

使用ndb_mgm STOP -f强制关闭节点，即使它触发了集群的完全关闭，当关闭足够数量的节点时，也可能会丢失数据，触发集群关闭，并且时间安排是这样SUMA的节点已经在关闭过程中。（漏洞#17772138）

内部 NdbEventBuffer::set_total_buckets()方法错误地计算了剩余桶数。SUB_START_CONF当信号无序到达时，这会导致任何不完整的纪元过早完成 。属于这个时期的任何事件后来都被忽略了，因此实际上丢失了，这导致模式更改没有在 SQL 节点之间正确分布。（错误#79635，错误#22363510）

在 SUSE Linux Enterprise Server 12 上编译 MySQL NDB Cluster 失败。（Bug #79429，Bug #22292329）

相对于非模式事件，模式事件被乱序附加到二进制日志。这是因为二进制日志注入器没有正确处理模式事件和非模式事件来自不同时期的情况。

此修复修改了对来自两个模式和非模式事件流的事件的处理，这样事件现在总是一次处理一个时期，从最早可用时期的事件开始，而不考虑它们发生在哪个事件流中。（错误#79077、错误#22135584、错误#20456664）

在NDB表 上执行时，ALTER TABLE ... DROP INDEX在实际删除索引之前对引用索引的内部数组进行更改，并且在删除未完成的情况下不会还原这些更改。这样做的一个影响是，在尝试删除具有外键依赖性的索引后，预期的错误引用了错误的索引，随后使用 SQL 修改该表的索引的尝试失败了。（错误#78980，错误#22104597）

NDB由于当前本地检查点的状态已设置但未处于活动状态，因此在节点重新启动期间失败，即使在这种情况下它可能具有其他状态。（错误#78780，错误#21973758）

ndbmtd检查仅在完整周期后发送的信号run_job_buffers，这是针对所有作业缓冲区输入执行的。现在这是作为run_job_buffers其自身的一部分完成的，这避免了长时间执行而不发送到其他节点或将信号刷新到其他线程。（错误#78530，错误#21889088）

参数设置的值spintime计算 ThreadConfig不正确，导致旋转持续时间比实际指定的时间长。（错误#78525，错误#21886476）

当NDBFS完成文件操作时，它用于唤醒主线程的方法在 Linux/x86 平台上有效，但在其他一些平台上无效，包括 OS X，这可能导致这些平台上不必要的减速。（错误#78524，错误#21886157）