不兼容 的更改：此处列出的更改跟进并进一步构建在 MySQL NDB Cluster 7.4.7 中完成的工作，以改进在插入过载条件下对本地检查点 (LCP) 的处理：

（错误#76890、错误#20981491、错误#77597、错误#21362758、错误#77612、错误#21370839）

参考资料：另请参阅：Bug #76742、Bug #20904721。

重要变更；NDB 复制： 添加了create_old_temporals 服务器系统变量以补充系统变量 avoid_temporal_upgrade，并 show_old_temporals在 MySQL 5.6.24 中引入，并在从 NDB 7.3.9 和 NDB 7.4.6 开始的 MySQL NDB Cluster 中可用。启用 create_old_temporals会导致 mysqldDATE在创建任何, DATETIME或 时使用 MySQL 5.6.4 之前采用的存储格式 TIMESTAMP——也就是说，创建列时不支持小数秒。create_old_temporals默认情况下禁用。系统变量是只读的；要启用 5.6.4 之前的时间类型，请设置等效选项 (--create-old-temporals) 在命令行上，或在 MySQL 服务器读取的选项文件中。

create_old_temporals仅在 MySQL NDB Cluster 中可用；标准 MySQL 5.6 服务器不支持它。它旨在促进从 MySQL NDB Cluster 7.2 升级到 MySQL NDB Cluster 7.3 和 7.4，之后受影响类型的表列可以升级到新的存储格式。create_old_temporals已弃用并计划在未来的 MySQL NDB Cluster 版本中删除。

avoid_temporal_upgrade还必须启用此功能才能正常工作。您也应该启用show_old_temporals 。有关详细信息，请参阅这些变量的说明。有关 MySQL 时间类型变化的更多信息，请参阅日期和时间类型存储要求。（漏洞 #20701918）

参考资料：另请参阅：Bug #21492598、Bug #72997、Bug #18985760。

当--database 没有为 ndb_show_tables指定选项，并且在数据库中找不到表时TEST_DB，现在会发出适当的警告消息。（错误#50633，错误#11758430）

重要变更；NDB Cluster APIs： MGM API 错误处理函数 ndb_mgm_get_latest_error(), ndb_mgm_get_latest_error_msg(), 和 句柄ndb_mgm_get_latest_error_desc() 一起使用时都失败了NULL您应该注意，虽然这些函数现在是 null 安全的，但在这种情况下返回的值是任意的且没有意义。（缺陷 #78130，缺陷 #21651706）

重要更改： 当ndb_restore在没有唯一索引的情况下运行 --disable-indexes或 --rebuild-indexes在具有唯一索引的表上运行时，可能会以导致重复值的顺序恢复行，从而导致它因重复键错误而失败。在这样的表上运行 ndb_restore现在需要至少使用这些选项之一；现在不这样做会导致错误。（错误#57782，错误#11764893）

参考资料：另请参阅：Bug #22329365、Bug #22345748。

NDB 复制： 当使用冲突检测和解决时 NDB$EPOCH2_TRANS()，删除-删除冲突未以事务方式处理。（缺陷号 20713499）

NDB Cluster API： 在执行时 dropEvent()，如果协调DBDICT器在订阅管理器（SUMA块）删除所有订阅之后但在协调器从系统表中删除事件之前失败，则删除的事件保留在表中，导致任何后续删除或创建事件同名失败并NDB出现错误 1419 订阅已删除或错误 746 事件名称已存在。即使在 dropEvent()使用非零力参数调用时也会发生这种情况。

现在在这种情况下，错误 1419 将被忽略，并 DBDICT从表中删除该事件。（缺陷号 21554676）

NDB Cluster API： 如果为事件缓冲区分配的内存总量超过大约 40 MB，则内存使用百分比的计算可能会在计算期间溢出。这是因为相关例程使用 32 位算术；现在已更改为使用Uint64 值。（错误#78454，错误#21847552）

NDB Cluster APIs： 该nextEvent2()方法继续返回异常事件，例如 TE_EMPTY，TE_INCONSISTENT和TE_OUT_OF_MEMORY对于已经被删除的事件操作。（错误#78167，错误#21673318）

NDB Cluster API： 在集群故障后初始重启节点后，当重启之前存在的事件后来被删除时，作为重启过程的一部分添加的集群故障事件被删除。这意味着，在这种情况下，事件 API 客户端无法知道需要进行故障处理。此外，用于最终清理已删除事件操作的 GCI 丢失了，这些操作由 pollEvents()并 nextEvent()在这些方法消耗了所有可用事件时执行。（错误#78143，错误#21660947）

NDB Cluster API： 当事件缓冲区的完整纪元插入事件队列时，表示最新全局检查点的内部值并不总是更新。当尝试为事件缓冲区中可用的事件获取正确的 GCI 时，Ndb::pollEvents()和 后续调用 pollEvents2()这也可能导致稍后调用 nextEvent()或 nextEvent2()查看尚未发现的事件。（错误#78129，错误#21651536）

执行从 MySQL NDB Cluster 7.2 到 MySQL NDB Cluster 7.4 的升级时， mysql_upgrade失败。这个问题的根本原因是代码意外重复mysql_fix_privilege_tables.sql，导致ndbinfo_offline模式过早关闭，进而导致后续 CREATE VIEW语句失败。（漏洞 #21841821）

ClusterMgr是 NDB API 和ndb_mgmd进程 的内部组件，TransporterFacade它们是传输器注册表的包装器的一部分，并与数据节点共享。该组件负责许多任务，包括连接设置请求；发送和监控心跳；提供节点状态信息；处理集群断开连接和重新连接；集群状态指标的转发。ClusterMgr维护活动节点的计数，该计数在收到节点已连接（reportConnected() 方法调用）的报告时递增，并在收到节点已从 断开连接（reportDisconnected()） 的报告时递减TransporterRegistry。此计数在检查范围内reportDisconnected()验证它是否大于零。

当节点连接由于发送缓冲区耗尽（以及其他潜在原因）而非常短暂并且刚刚描述的检查失败时，就会出现此处解决的问题。发生这种情况是因为，当一个节点没有完全连接时， reportDisconnected()尽管连接尚未报告给 ，但连接尝试仍然有可能触发调用 ClusterMgr；reportConnected()因此，和 的配对 reportDisconnected()不保证调用，这可能导致连接节点的计数被设置为零，即使仍然有节点实际上仍然连接，导致节点崩溃与 MySQL NDB Cluster 的调试构建，以及潜在的错误或其他不利影响与发布建立。

为了解决这个问题， ClusterMgr::reportDisconnected()现在验证一个断开连接的节点实际上已经完全完成连接，然后检查并减少连接节点的数量。（错误#21683144，错误#22016081）

参考资料：另请参阅：Bug #21664515、Bug #21651400。

为了降低节点的环回传输器因发送缓冲区耗尽而与传输器注册表断开连接的可能性 reportError()（通过修复 Bug #21651400 实现），现在保留了一部分发送缓冲区供此传输器使用。（错误#21664515，错误#22016081）

参考资料：另请参阅：Bug #21651400、Bug #21683144。

环回传输器类似于 TCP 传输器，但节点使用它向自身发送信号作为许多内部操作的一部分。与 TCP 传输器一样，它可能会因某些情况（包括发送缓冲区耗尽）而断开连接，但这可能会导致阻塞， TransporterFacade从而导致ndb_mgmd或 API 节点进程中出现多个问题。为防止这种情况，环回传输器断开连接的节点现在只需关闭，而不是让节点进程挂起。（漏洞 #21651400，漏洞 #22016081）

参考资料：另请参阅：Bug #21683144、Bug #21664515。

当此操作失败时停止订阅时，内部NdbEventBuffer对象的活动订阅计数 ( m_active_op_count) 可能会多次递减，例如，由于服务器繁忙并被重试。当与数据节点的通信失败时，例如发生超时时，此计数的递减也可能失败。（漏洞 #21616263）

参考资料：此问题是 Bug #20575424、Bug #20561446 的回归。

在某些情况下，管理服务器守护程序在启动时失败但未报告原因。现在，当 ndb_mgmd由于错误而无法启动时，错误消息将打印到stderr. （漏洞 #21571055）

在具有多个 LDM 实例的 MySQL NDB Cluster 中，所有实例都写入节点日志，即使是其他节点上的非活动实例。在重新启动期间，这导致日志中充满了来自其他节点的消息，例如此处显示的消息：

2015-06-24 00:20:16 [ndbd] INFO     -- We are adjusting Max Disk Write Speed,
a restart is ongoing now
...
2015-06-24 01:08:02 [ndbd] INFO     -- We are adjusting Max Disk Write Speed,
no restarts ongoing anymore

现在，此日志记录仅由活动的 LDM 实例执行。（缺陷号 21362380）

备份期间备份块状态报告不正确。（缺陷号 21360188）

参考资料：另请参阅：Bug #20204854、Bug #21372136。

添加了 BackupDiskWriteSpeedPct 数据节点参数。设置此参数会导致数据节点在执行备份时保留其最大写入速度的百分比（由 的值确定 MaxDiskWriteSpeed）用于本地检查点。 BackupDiskWriteSpeedPct被解释为百分比，可以设置在 0 到 90 之间（含 0 和 90），默认值为 50。（错误 #20204854）

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

当已知数据节点在给定的全局检查点被集群中的其他节点激活，但它 sysfile报告较低的 GCI 时，较高的 GCI 用于确定数据节点可以重新创建哪个全局检查点。当正在启动的数据节点有一个干净的文件系统（GCI = 0），或者当它在其他节点后面有多个全局检查点时，这会导致问题。

现在在这种情况下，只有当它最多领先一个 GCI 时，才会使用其他节点已知的更高 GCI。（漏洞#19633824）

参考资料：另请参阅：Bug #20334650、Bug #21899993。此问题是 Bug #29167 的回归。

--include-databases当使用or --exclude-databases选项 恢复一个或多个特定数据库时 ， ndb_restore尝试将外键应用于数据库中的表，这些表不在被恢复的数据库中。（漏洞 #18560951）

使用ndb_restore 从备份恢复数据库模式后 ，在具有多个语句的事务中自动发现恢复的表无法正常工作，导致在尝试获取锁时发现死锁；尝试重新启动事务错误。

在mysql 客户端中以及当此类事务由使用 Connector/J 和可能的其他 MySQL API 的应用程序执行时都会遇到此问题。

在升级之前，可以通过 SELECT TABLE_NAME, TABLE_SCHEMA FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE = 'NDBCLUSTER' 在执行任何其他语句之前在还原操作之后的所有 SQL 节点上执行来解决此问题。（漏洞 #18075170）

inet_ntoa()在多个mgmd线程内部使用 的函数不是 POSIX线程安全的，这意味着它返回的结果有时可能是未定义的。为了避免这个问题，一个线程安全和平台无关的包装器 inet_ntop()被用来代替这个函数。（漏洞#17766129）

当针对 包含一个或 --extra-partition-info多个 . 列。（漏洞 #14695968）--blob-infoTINYBLOB

与内部事件数据缓冲区中的全局检查点相关的操作有时可能会泄漏内存。（错误#78205，错误#21689380）

参考资料：另请参阅：Bug #76165、Bug #20651661。

当复合外键中的列之一是表的主键时，尝试NDB使用引用父表的复合主键的复合外键创建表失败，此外，该列也有一个唯一键。（错误#78150，错误#21664899）

当尝试启用索引统计时，当多个使用索引统计的mysqld进程与启动、重新启动或停止集群或节点故障处理同时启动时，创建所需的系统表、事件和事件订阅通常会失败。这通常是可恢复的，因为受影响的mysqld进程可以（并且确实）在不久之后重试这些操作。因此，此类故障不再记录为警告，而仅记录为信息性事件。（错误#77760，错误#21462846）

NDB当表已有外键时，向表 添加唯一键失败。在升级之前，您可以通过先创建唯一键，然后使用单独的 ALTER TABLE语句添加外键来解决此问题。（错误#77457，错误#20309828）