重要变化： 以前，ndbinfo 信息数据库包含使用 MyISAM存储引擎的查找表。这种对 的依赖MyISAM现已被移除。（缺陷号 20075747）

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

重要更改： 许多 MySQL NDB Cluster 数据节点配置参数在早期版本的 MySQL NDB Cluster 中已弃用，并已在此版本中删除。这些参数包括 Id, NoOfDiskPagesToDiskDuringRestartTUP, NoOfDiskPagesToDiskDuringRestartACC, NoOfDiskPagesToDiskAfterRestartACC, NoOfDiskPagesToDiskAfterRestartTUP, ReservedSendBufferMemory, MaxNoOfIndexes, 和 Discless（Diskless 改为使用），以及DiskCheckpointSpeed和 DiskCheckpointSpeedInRestart。陈旧和未使用的ByteOrder计算机配置参数也已被删除，以及未使用的 MaxNoOfSavedEvents管理节点配置参数。不再支持这些参数；他们中的大多数已经没有（或不再有）任何影响。尝试在 MySQL NDB Cluster 配置文件中使用这些参数中的任何一个现在都会导致错误。

有关更多信息，请参阅 NDB Cluster 7.5 中的新增功能。（错误#77404，错误#21280428）

重要更改： 由于以下ndbinfo数据库现在可以提供有关 MySQL NDB Cluster 节点配置参数的默认和当前信息：

您可以使用这两个表上的连接按名称获取 MySQL NDB Cluster 配置参数的值，如下所示：

SELECT  p.param_name AS Name,
        v.node_id AS Node,
        p.param_type AS Type,
        p.param_default AS 'Default',
        v.config_value AS Current
FROM    config_params p
JOIN    config_values v
ON      p.param_number = v.config_param
WHERE   p. param_name IN ('NodeId', 'HostName','DataMemory', 'IndexMemory');

（错误#71587，错误#18183958）

重要更改：管理、数据和 API 节点 的ExecuteOnComputer配置参数现已弃用，并且可能会在未来的 MySQL NDB Cluster 版本中删除。对于所有类型的 MySQL NDB Cluster 节点，您现在应该使用该 HostName参数专门用于标识集群配置文件中的主机。

此信息现在也显示在 ndb_config 的输出中。（错误#53052，错误#11760628）--configinfo --xml

NDB 复制： 通常，RESET SLAVE导致从 mysql.ndb_apply_status表中删除所有条目。此版本添加了ndb_clear_apply_status 系统变量，可以覆盖此行为。这个变量是ON默认的；将其设置为OFF防止RESET SLAVE清除 ndb_apply_status表格。（漏洞 #12630403）

不推荐使用的 MySQL NDB Cluster 节点配置参数现在由ndb_config 指示。对于当前弃用的每个参数，XML 输出中的相应 标记现在包含属性。（漏洞 #21127135）--configinfo --xml<param/>deprecated="true"

添加了mysqld--ndb-cluster-connection-pool-nodeids的 选项，可用于通过节点 ID 指定节点列表以进行连接池。列表中节点 ID 的数量必须等于为 设置的值 。（漏洞 #19521789）--ndb-cluster-connection-pool

在ndb_mgm客户端中 添加了PROMPT命令 。此命令的语法为 ，它将客户端的提示符设置为 。发出不带参数的命令会导致提示重置为默认值 ( )。有关更多信息，请参阅 NDB Cluster Management Client 中的命令。（漏洞#18421338）PROMPT stringstringndb_mgm>

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

存储引擎现在使用改进的NDBrecords-per-key 接口用于 MySQL 5.7 中为优化器引入的索引统计信息。此处列出了由于此更改而导致的一些改进：

不相容的变化；NDB Cluster API：pollEvents2()只要时间参数使用负值， 该（缺陷号 20762291）

重要变更；NDB Cluster APIs： Ndb::pollEvents()现在与MySQL NDB Cluster 7.4.3 中引入的 、 和 event 类型TE_EMPTY兼容 TE_INCONSISTENT。 TE_OUT_OF_MEMORY有关此更改的详细信息，请参阅 MySQL NDB Cluster API 开发人员指南中对此方法的描述。（缺陷号 20646496）

重要变更；NDB Cluster API： 将方法添加 Ndb::isExpectingHigherQueuedEpochs() 到 NDB API 以检测何时检测到额外的、更新的事件纪元 pollEvents2()。

的行为 Ndb::pollEvents()也已修改，现在 当检测到集群故障时它返回NDB_FAILURE_GCI（等于 ）。~(Uint64) 0（漏洞 #18753887）

重要变更；NDB Cluster APIs： 为了释放用于删除事件操作的内存，事件 API 以前依赖于 pollEvents()并 nextEvent()消耗所有可能引用删除事件的事件。前两种方法之间的这种依赖关系 dropEventOperation()要求在尝试释放事件操作内存之前读取整个事件缓冲区（即，直到连续调用pollEvents() 并nextEvent()不再返回任何事件）。

事件缓冲区重置后出现了一个相关的清理问题（当所有事件操作之前都被删除时），事件缓冲区被 createEventOperation()重置后的第一次调用截断。

为了解决这些问题，事件缓冲区现在在最后一个事件操作被删除时被清除，而不是等待后续的创建操作（可能会或可能不会发生）。当事件队列被清除时，丢弃的事件操作占用的内存现在也会被释放，这消除了消耗所有事件以释放内存的隐藏要求。此外，事件操作内存现在会在所有引用操作的事件都被消耗后立即释放，而不是等待整个事件缓冲区被消耗。（错误#78145，错误#21661297）

重要变更；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 Cluster API： 以下 NDB API 方法实际上并未实现，并已从源代码中删除：

重要变化： 控制程序行为的选项 NDB在连续尝试连接到管理服务器的次数和时间方面已发生变化，如下所列：

（漏洞 #22116937）

重要变化： 在以前版本的 MySQL NDB Cluster 中，其他 DDL 操作不能成为 ALTER ONLINE TABLE ... RENAME .... （BUG#16021021 的修复不允许这样做。）MySQL NDB Cluster 7.5 进行了以下更改：

（错误#20804269、错误#76543、错误#20479917、错误#75797）

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

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

NDB 复制： 当二进制日志注入器线程处理失败事件时，所有NDB表都可能无限期地处于只读模式。这是由于二进制日志注入器线程和处理 ndb_schema 表上的事件的实用程序线程之间的竞争条件，以及在处理失败事件时，二进制日志注入器线程将所有NDB表置于只读模式直到所有处理此类事件并且线程自行重新启动。

当二进制日志注入线程接收到一组一个或多个失败事件时，它会丢弃所有其他现有的事件操作，并且在它处理完所有失败事件然后重新启动自身之前，不再期望来自实用程序线程的事件。但是，实用程序线程有可能在注入器线程处理故障时继续尝试二进制日志设置，从而尝试在这些表上创建模式分布表和事件订阅。如果这些表的创建和事件订阅发生在这段时间内，则二进制日志注入器线程对没有进一步的事件操作的期望永远不会满足；因此，注入器线程永远不会重新启动，并且NDB如前所述，表格保持只读状态。

为了解决这个问题，Ndb 处理模式事件的对象现在在ndb_schema表删除事件被处理后肯定会被删除，这样实用程序线程就不能创建任何新的事件，直到注入器线程重新启动，此时，一个新的 Ndb对象来处理模式事件被创建。（错误#17674771、错误#19537961、错误#22204186、错误#22361695）

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

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

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

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

NDB Cluster API：多个线程 创建和销毁 Ndb_cluster_connection对象可能会使用相同的应用程序锁，这在某些情况下会导致全局字典缓存失败。为了缓解这个问题，已经序列化了几个内部 NDB API 对象的创建和销毁。（缺陷号 20636124）

NDB Cluster APIs： 当一个Ndb在集群失败之前创建的对象被重用时，这个对象的事件队列仍然可以包含来自失败之前的数据节点事件。这些事件可以引用 “旧”时期（从失败发生之前开始），这反过来又可能违反该 nextEvent()方法所做的时期数总是增加的假设。此问题已通过在此类情况下明确清除事件队列得到解决。（漏洞#18411034）

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

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

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

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

在 MySQL NDB Cluster 7.4.8 中无意中引入了一个严重的回归，本地检查点和重启通常花费比预期更长的时间。发生这种情况是因为 MaxDiskWriteSpeedOwnRestart 在重新启动期间忽略 了 的设置，而是使用MaxDiskWriteSpeedOtherNodeRestart了 的值（默认情况下远低于 的默认值 MaxDiskWriteSpeedOwnRestart）。此问题仅影响重启时间和性能，对正常操作没有任何影响。（漏洞 #22582233）

集群日志中提供的最新可恢复检查点的纪元作为其 EventBufferStatus事件报告的一部分（请参阅 NDB Cluster: Messages in the Cluster Log）没有明确定义，因此不可靠；根据各种因素，报告的纪元可能是当前正在使用的纪元、最近使用的纪元或正在排队等待使用的下一个纪元。

此修复确保最新的可恢复全局检查点始终被视为用户最近完全使用的检查点，因此它是生成报告时存在的最新可恢复全局检查点。（缺陷号 22378288）

添加了 mysqld--ndb-allow-copying-alter-table的选项 。设置此选项（或等效的系统变量 ）以 防止语句执行复制操作。默认值为。（缺陷号 22187649）ndb_allow_copying_alter_tableOFFALTER TABLEON

参考资料：另请参阅：错误 #17400320。

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

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

在具有多个 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。

对于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。

以前，可以调用多个发送线程来处理对同一节点的发送；然后这些线程竞争同一个发送锁。虽然发送锁阻塞了额外的发送线程，但工作线程可以传递给其他节点。

此问题已通过确保在已将活动发送线程分配给同一节点时不激活新发送线程来解决。此外，已经分配有活动发送线程的节点不再对其他已经活动的发送线程可见；也就是说，当一个发送线程当前分配给它时，这样的节点不再被添加到节点列表中。（缺陷 #20954804，缺陷 #76821）

重做日志过载（API 节点配置参数）时挂起的操作排队DefaultOperationRedoProblemAction 可能会导致数据节点用完重做日志空间时超时（P_TAIL_PROBLEM错误）。现在，当重做日志已满时，节点会中止请求而不是将它们排队。（缺陷号 20782580）

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

NDB事件缓冲区可与 对象一起使用Ndb以订阅表级行更改事件流。用户订阅现有事件；这会导致数据节点开始向对象发送事件数据信号 ( SUB_TABLE_DATA) 和纪元完成信号 ( SUB_GCP_COMPLETE) Ndb。 SUB_GCP_COMPLETE_REP在用于启动订阅的内部方法调用完成之前，信号可以到达并发接收器线程中执行。

信号的执行SUB_GCP_COMPLETE_REP取决于SUMA桶（子数据流）的总数，但这可能尚未设置，导致当前问题，当用于跟踪 SUB_GCP_COMPLETE_REP信号的计数器 ( TOTAL_BUCKETS_INIT) 被发现设置为错误值时。现在TOTAL_BUCKETS_INIT进行测试以确保它在使用前已正确设置。（缺陷 #20575424，缺陷 #76255）

参考资料：另请参阅：Bug #20561446、Bug #21616263。

NDBndb_index_stat_option当被查询的索引被标记为内部错误时，统计查询可能会被设置的错误延迟延迟 （默认 60 秒）。当对具有多个索引的表执行时，同样的潜在问题也可能导致 ANALYZE TABLE挂起，NDB其中一个或多个但不是所有索引发生内部错误。

现在在这种情况下，将立即返回任何现有统计信息，而无需等待发现任何其他统计信息。（错误#20553313、错误#20707694、错误#76325）

获取表或数据库列表时分配的内存之后没有释放。（缺陷 #20234681，缺陷 #74510）

参考资料：另请参阅：Bug #18592390、Bug #72322。

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

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

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

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

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

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

当使用足够大的值 TransactionDeadlockDetectionTimeout 和默认值时 sort_buffer_size，执行 多个并发的冲突或死锁事务，每个事务都有几个挂起的操作，导致运行查询的 SQL 节点失败。（漏洞 #16731538，漏洞 #67596）SELECT * FROM ndbinfo.cluster_operations ORDER BY transid

该ndbinfo.config_params 表现在是只读的。（错误#11762750，错误#55383）

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

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

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

当发送缓冲区成为限制资源时，可能会锁定发送缓冲区互斥锁，原因可能是发送缓冲区资源配置不足、通信缓慢或失败导致所有发送缓冲区耗尽的问题，或者接收器速度慢无法发送消耗发送的内容。在这种情况下，工作线程无法为信号分配发送缓冲区内存，并试图强制发送以释放空间，同时发送线程正忙于尝试发送到同一个或多个节点。所有这些线程都在争夺发送缓冲区互斥锁，这导致了已经描述过的锁，由看门狗报告为 Stuck in Send. 此修复分为两部分，在此处列出：

（缺陷 #77081，缺陷 #21109605）