NDB 集群 API；ndbinfo 信息数据库： 向信息数据库添加了两个表 ndbinfo。该config_nodes表提供有关配置为给定 NDB Cluster 的一部分的节点的信息，例如节点 ID 和进程类型。该 processes表显示有关当前连接到集群的节点的信息；此信息包括进程名称和系统进程 ID，以及服务地址。对于每个数据节点和SQL节点，它还显示了该节点的天使进程的进程ID。

作为实现该 processes表所做工作的一部分，一个新 set_service_uri() 方法已添加到 NDB API。

有关详细信息，请参阅 ndbinfo config_nodes Table和 ndbinfo processes Table以及 Ndb_cluster_connection::set_service_uri()。

NDB Cluster APIs： NDB cluster 的系统名称现在 作为状态变量的值 在mysqlNdb_system_name客户端中可见，也可以通过 NDB API 应用程序使用该 Ndb_cluster_connection::get_system_name() 方法获取。可以使用 集群配置文件部分中 Name参数 [system]

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

向ndb_config 添加了--query-all选项。此选项的行为与 选项非常相似，只是 （缩写形式：）一次转储所有属性的配置信息。（缺陷 #60095，缺陷 #11766869）--query--query-all-a

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

（缺陷 #85679，缺陷 #25799465）

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

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

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

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

ndb_report_thresh_binlog_epoch_slip 启用后，当事件缓冲区使用率很高时，事件缓冲区状态消息 会 report_reason=LOW/ENOUGH_FREE_EVENTBUFFER打印在日志中，然后降低到较低水平。该计算基于分配的事件缓冲区内存总量，而不是 ; 设置的限制 ndb_eventbuffer_max_alloc；即使事件缓冲区具有无限内存（ndb_eventbuffer_max_alloc= 0，默认值），它也会被打印出来，这可能会使用户感到困惑。

这是固定的，如下所示：

（缺陷号 25726723）

批量更新是通过读取记录并在记录集上执行事务来执行的，该事务在读取记录时启动。当事务初始化失败时，事务执行器函数随后没有意识到发生了这种情况，从而导致 SQL 节点故障。通过在尝试初始化事务时提供适当的错误处理来解决此问题。（缺陷号 25476474）

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

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

对主键大于80字节的表 执行在线 ALTER TABLE ... REORGANIZE PARTITION语句 导致数据节点重启，导致重组失败。NDB（漏洞#25152165）

在某些情况下，失败的 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）

计划关闭具有超过 10 个数据节点的 NDB Cluster 并不总是正常执行。（缺陷号 20607730）

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

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

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

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

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

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

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

当要添加的键具有同一个表上现有外键的名称时尝试执行 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）

使用长信号格式的丢弃TRANS_AI信号未由DBTC 内核块处理。（缺陷 #85606，缺陷 #25777337）

参考资料：另请参阅：Bug #85519、Bug #27540805。

为了防止扫描返回比客户端保留缓冲区更多的行、字节或两者， DBTUP内核块 在发送给请求 块TRANSID_AI的信号中报告它已发送给客户端 的大小。知道可用于结果集的最大批处理大小，如果超过，则终止扫描批处理。 TUPKEYCONFDBLQHDBLQH

该DBSPJ块的FLUSH_AI 属性允许从同一行DBTUP生成两个 TRANSID_AI结果，一个用于客户端，一个用于DBSPJ，这是在连接表上进行键查找所需要的。这两个的大小都被添加到 DBTUP块报告的读取长度中，这导致控制 DBLQH块认为它消耗了比实际情况更多的可用最大批大小，从而导致扫描批提前终止，这可能对 SPJ 扫描的性能产生负面影响。为更正此问题，在这种情况下，现在仅报告 API 请求的实际读取长度部分。（缺陷 #85408，缺陷 #25702850）

在 SPARC 平台上使用 Oracle Developer Studio 12.5 构建的 Solaris 11 的数据节点二进制文件因总线错误而失败。（漏洞 #85390，漏洞 #25695818）

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