mysqladmin被添加到 Docker/Minimal 包中，因为 InnoDB Cluster 需要它。（缺陷号 25998285）

重要变更；MySQL NDB ClusterJ： NDB Cluster 不再支持 OpenJPA 的 ClusterJPA 插件，并且已从发行版中删除。（缺陷号 23563810）

NDB 复制： 添加了 mysqld--ndb-log-update-minimal日志记录选项。此选项导致仅将主键值写入前映像，并且仅在后映像中更改列。（缺陷号 24438868）

MySQL NDB ClusterJ： 实现了一个新的自动重新连接功能，以方便处理连接问题。通过为新的连接属性设置一个正数来启用该功能 com.mysql.clusterj.connection.autoreconnect.timeout，该属性指定超时期限的长度（以秒为单位）。如果发生连接错误，ClusterJ 会在应用程序关闭所有会话后尝试将应用程序重新连接到 NDB Cluster；如果应用程序没有在超时期限内关闭所有会话，ClusterJ 将强制关闭任何打开的部分，然后尝试重新连接。有关详细信息，请参阅 错误处理和重新连接。

在某些关键情况下，例如数据节点故障，产生的日志消息量可能会导致文件系统和其他问题，从而使问题更加复杂，因为这些消息是使用同步记录的 stdout。为了防止这种情况发生，来自工作线程的日志消息现在使用非阻塞的日志缓冲区，因此在这种情况下不太可能干扰其他进程。（缺陷号 24748843）

添加了ndb_config--diff-default的 选项。此选项使程序仅打印那些具有不同于默认值的参数。（缺陷 #85831，缺陷 #25844166）

在基于 unix 的平台上 添加了ndb_top程序。此实用程序显示NDB数据节点的 CPU 负载和使用信息，并定期更新（默认情况下每秒更新一次）。显示为文本或彩色ASCII图形格式；两种格式可以同时显示。也可以禁用图形的颜色输出。

ndb_top连接到 NDB Cluster SQL 节点（即 MySQL 服务器），因此必须能够作为 SELECT对数据库中的表具有特权 ndbinfo。

ndb_top当前不适用于 Windows 平台。

有关详细信息，请参阅 ndb_top — 查看 NDB 线程的 CPU 使用信息。

打包： 两个缺少的依赖项被添加到 apt包中：

（缺陷 #85679，缺陷 #25799465）

NDB 磁盘数据： 如果节点发生故障时磁盘表的表空间已被完全消耗，并且表行被删除和插入 - 或者使用收缩或扩展的磁盘列值进行更新 - 而节点不可用，则随后的重启可能会失败并显示错误 1601超出范围，表空间已满。我们通过保留 4% 的表空间供节点启动期间使用来防止这种情况发生。（缺陷号 25923125）

NDB 复制： 添加了一个检查以在检测到配置为多线程从属时停止NDB复制从属（例如，如果 slave_parallel_workers设置为非零值）。（缺陷号 21074209）

NDB Cluster APIs： 实现方法 NdbDictionary::NdbTableImpl::getColumn()，在 NDB API 的许多地方使用，其中列按名称引用，已变得更加高效。此方法使用列数组的线性搜索来查找正确的列对象，这对于包含许多列的表可能效率低下，并被检测为客户应用程序中 CPU 的大量使用。（理想情况下，用户应该执行名称到列对象的映射，然后在方法调用中使用列 ID 或对象，但实际上并不总是这样做。）以前用于名称查找的成本较低的哈希索引实现是恢复具有相对多列的表。（线性搜索继续用于具有较少列的表，其中性能差异可以忽略不计。

NDB Cluster API： NDB 错误 631 被重新分类为（临时）节点恢复错误Scan take over error, restart scan transaction。这以前作为内部（和永久性）错误暴露给应用程序，没有提供任何描述。（漏洞 #86401，漏洞 #26116231）

MySQL NDB ClusterJ： 运行 ClusterJ 的单元测试时，跳过了 JTie 和 NDB JTie 测试。（缺陷号 26088583）

MySQL NDB ClusterJ：NDB JTie 测试编译失败。这是由于空引用的处理方式所致，已通过此修复程序得到纠正。（缺陷号 26080804）

.log由于过滤掉同一节点组中其他节点记录的更改的问题， 备份文件包含一个或多个额外片段的日志条目。这导致.log文件更大，因此使用了比必要更多的资源；它还可能在恢复时引起问题，因为在应用日志时来自不同节点的备份可能会相互干扰。（缺陷号 25891014）

片段创建期间的内存耗尽导致集群意外关闭。同时向大量列添加唯一键可能会触发此问题。（漏洞 #25851801）

当对重做日志文件进行最终写入时，预计下一个日志文件已经打开用于写入，但磁盘速度较慢时情况并非总是如此，从而导致节点故障。现在在这种情况下NDB等待下一个文件在尝试写入之前正确打开。（缺陷号 25806659）

数据节点线程可以绑定到单个 CPU 或一组 CPU，一组 CPU 在内部表示 NDB为SparseBitmask. 尝试锁定一组 CPU 时，CPU 使用率过高，因为执行锁定的例程使用了该方法，该方法查找在 (2 ³² -2，或 4294967294 mt_thr_config.cpp::do_bind()) 的整个理论范围内设置的位). 这是通过使用 修复的，它可用于仅迭代实际设置的那些位。（漏洞#25799506）SparseBitmaskSparseBitmask::getBitNo()

设置 NoOfFragmentLogParts 为每个本地数据管理器有超过 4 个重做日志部分会导致资源耗尽和随后的多个数据节点故障。由于这是一个无效的配置，因此添加了一个检查来检测每个 LDM 具有超过 4 个重做日志部分的配置，并将其视为无效而拒绝。（缺陷号 25333414）

在某些情况下，失败的 ALTER TABLE ... ADD UNIQUE KEY语句可能会导致 SQL 节点失败。（漏洞#24444878）

参考资料：此问题是 Bug #23089566 的回归。

当外键触发器列与触发器执行期间提供给它们的值不匹配时，会引发错误 240，但没有错误消息指示问题的来源。（漏洞 #23141739）

参考资料：另请参阅：Bug #23068914、Bug #85857。

如果 LDM 块的数量不能被 TC/SPJ 块的数量整除，则 SPJ 请求不会平均分布在可用的 SPJ 实例上。现在，循环分配用于更有效地在所有可用的 SPJ 实例之间分配 SPJ 请求。

作为这项工作的一部分，一些未使用的成员变量已从类中删除Dbtc。（漏洞 #22627519）

ALTER TABLE .. MAX_ROWS=0现在只能通过使用复制ALTER TABLE语句来执行。MAX_ROWS无法再使用重置 为 0 ALGORITHM=INPLACE。（缺陷号 21960004）

在系统重新启动期间，当一个节点因未发送心跳而发生故障时，所有其他节点仅报告另一个节点发生故障而没有任何其他信息。现在在这种情况下，错误日志和数据节点日志都会报告心跳丢失的事实以及发送心跳失败的节点的 ID。（缺陷号 21576576）

由于之前的问题，当查询涉及 a 时，优化和执行阶段之间的分离不明确 GROUP BY，join-pushable 评估器不确定其优化的查询执行计划是否实际上是可推送的。出于这个原因，这样的分组连接总是被认为是不可推送的。已确定分离问题已通过 MySQL 5.6 中已完成的工作得到解决，因此我们现在删除此限制。（漏洞 #86623，漏洞 #26239591）

当删除表中的所有行后紧跟 时 DROP TABLE，可能DBACC哈希索引的收缩在删除之前尚未准备好。这种收缩是一个不检查表状态的每个片段操作。当一个表被drop时，DBACC释放资源，期间分片大小和页目录的描述不一致；这可能会导致读取陈旧页面和未定义的行为。

由于散列索引的扩展，插入大量行然后删除表也应该有这样的效果。

为了解决这个问题，我们确保当一个片段即将被释放时，这个片段上没有挂起的扩展或收缩操作。（错误#86449，错误#26138592）

IndexMemory尽管该参数已被弃用，但 一些错误消息仍被引用 。（漏洞 #86385，漏洞 #26107514）

内部函数从信号execute_signals()中 mt.cpp读取三个部分指针，即使没有传递给它。这基本上是无害的，尽管没有必要。当读取的信号是作业缓冲区最后一页上的最后一个信号时，并且内存中的下一页未映射或无法访问时， ndbmtd失败并出现错误。为了防止这种情况发生，该函数现在只读取实际传递给它的节指针。（漏洞 #86354，漏洞 #26092639）

在 Dbacc 中最多有一次尝试删除删除表时释放的哈希索引页。这意味着，对于大分区（32 页或更多），总会有一些页面丢失。现在，当使用它们的表被删除时，所有哈希索引页都被释放。（漏洞 #86247，漏洞 #26030894）

当NDB由于违反外键约束而导致对表的查询失败时，错误消息中不会显示有关外键的任何有用信息，其中仅包含文本Unknown error code。（错误#86241，错误#26029485，错误#16371292）

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

ndb_show_tables程序 选项在设置为 0（假）时无法正常工作；--unqualified这应该禁用该选项，从而导致在输出中打印完全限定的表名和索引名。（漏洞 #86017，漏洞 #25923164）

当NDB创建带有外键约束的表时，首先创建其索引，然后在创建外键时，将这些索引加载到 NDB字典缓存中。当 CREATE TABLE语句由于与外键相关的问题而失败时，缓存中已有的索引不会失效。这意味着任何 CREATE TABLE具有与失败语句中的名称相同的索引的后续结果都会产生不一致的结果。现在，在这种情况下，任何以 failed 命名的索引都会 CREATE TABLE立即从缓存中失效。（缺陷 #85917，缺陷 #25882950）

在本地检查点期间，记录大小是从 DBTUP内核块中获取的。在 LCP 扫描完成之前，此记录大小一直在使用，这使得在向表中添加列DBTUP的提交时更新最大记录大小成为可能ALTER TABLE，这可能导致 LCP 期间的节点故障。现在记录大小是在更新它不会导致这种情况的时候获取的。（漏洞 #85858，漏洞 #25860002）

当要添加的键具有同一个表上现有外键的名称时尝试执行 ALTER TABLE ... ADD FOREIGN KEY失败，并显示错误消息。（漏洞 #85857，漏洞 #23068914）

节点内部调度程序（在 中mt.cpp）收集关于它自己的进度和它正在执行的任何未完成工作的统计信息。其中一项统计数据是未完成的发送字节数，收集在 send_buffer::m_node_total_send_buffer_size. 此信息稍后可能会被发送线程调度程序使用，发送线程调度程序将其用作调整其自身发送性能与延迟的指标。

为了减少内部发送缓冲区上的锁争用，它们被分成两thr_send_buffer 部分，m_buffer和 m_sending，每个部分都由自己的互斥体保护，它们的组合大小由 表示 m_node_total_send_buffer_size。

对代码的调查表明，对于使用哪个互斥量更新 没有一致性， m_node_total_send_buffer_size结果是没有对该值的并发保护。为避免这种情况，m_node_total_send_buffer_size 被替换为两个值m_buffered_size 和m_sending_size，它们分别跟踪两个缓冲区的大小。这些计数器在分别保护每个缓冲区的两个不同互斥锁的保护下更新，现在加在一起以获得总大小。

建立并发控制后，部分计数的更新现在应该是正确的，以便它们的组合值不再随着时间的推移累积错误。（缺陷 #85687，缺陷 #25800933）

允许使用短信号或压缩短信号 TRANSID_AI将结果发送 DBSPJ回客户端 API。（漏洞 #85545，漏洞 #25750355）

参考资料：另请参阅：Bug #85525、Bug #25741170。

BatchByteSize 信号中发送 的最大值SCANREQ并不总是正确设置以反映客户端结果缓冲区中可用的有限字节大小。结果缓冲区大小计算已被修改，以便有效批处理字节大小准确反映数据节点可能返回的最大值，以防止结果缓冲区可能溢出。（漏洞 #85411，漏洞 #25703113）

使用 gcc版本 6.0.0 或更高版本编译 NDB 内核时，现在使用-flifetime-dse=1. （缺陷 #85381，缺陷 #25690926）