不兼容的更改;NDB盘数据:由于磁盘文件格式的变化，需要执行——初始升级到此版本或从此版本降级时，重新启动每个数据节点。

重要的变化;NDB盘数据:NDB集群通过实现局部本地检查点(lcp)，提高了节点重启时间和更大数据集的整体性能。在此版本之前，LCP总是生成整个数据库的副本。

NDB现在支持写入单个记录的LCP，因此LCP不再严格地需要写入整个数据库。由于在恢复时仍然需要完全恢复数据库，因此策略是在每个LCP上保存四分之一的所有记录，并写入自上一个LCP以来已更改的记录。

在这个版本中引入了两个与此更改相关的数据节点配置参数:EnablePartialLcp(默认真正的，或enabled)启用部分LCPs。当启用部分lcp时，RecoveryWork控制分配给LCPs的空间百分比;它随着重新启动期间lcp上必须执行的工作量而增加，而不是在正常操作期间执行的工作量。提高这个值会使正常操作期间的lcp需要写入更少的记录，从而减少通常的工作负载。提高这个值也意味着重启需要更长的时间。

此外，的默认值为StartPartitionedTimeout从60000更改为0。

该版本还弃用了数据节点配置参数BackupDataBufferSize，BackupWriteSize,BackupMaxWriteSize；在未来的NDB集群版本中，这些都将被删除。(错误# 27308632)

重要的变化:添加了ndb_perrorNDB集群错误码信息获取工具。这个工具代替了perror——ndb；的——ndb选择perror现在已弃用，并在使用时发出警告;该选项可能会在未来的NDB版本中被删除。

看到ndb_perror -获取NDB Error Message信息，以查询更多资料。(Bug #81703, Bug #81704, Bug #23523869, Bug #23523926)

参考文献:参见Bug #26966826, Bug #88086。

现在可以指定一组内核，用于执行有序索引的离线多线程构建的I/O线程，而不是像文件I/O、压缩或解压缩这样的普通I/O任务。”离线”在此上下文中，指的是在父表未被写入时执行的有序索引的构建;这样的建筑发生在NDB群集执行节点或系统重新启动，或作为从备份中恢复群集的一部分ndb_restore——rebuild-indexes．

此外，离线索引构建工作的默认行为被修改为使用可用的所有核心ndbmtd，而不是将其自身限制到为I/O线程保留的核心。这样做可以提高重启和恢复时间、性能、可用性和用户体验。

此增强的实现如下:

此外,NDB现在区分可访问的线程类型”ThreadConfig”根据以下两个标准:

如需了解更多信息，请参见手册中各参数的说明。(Bug #25835748, Bug #26928111)

添加了ODirectSyncFlag数据节点的配置参数。当启用时，数据节点将所有已完成的文件系统写入重做日志视为已使用fsync．

(错误# 25428560)

添加了ndbinfo.error_messages该表提供了NDB集群错误信息，包括错误码、状态类型、简要描述和分类。中使用SQL获取错误信息成为可能mysql客户端(或其他MySQL客户端程序)，像这样:

SELECT * FROM ndbinfo。WHERE error_code='321';+------------+----------------------+-----------------+----------------------+ | error_code | error_description | error_status | error_classification  | +------------+----------------------+-----------------+----------------------+ | 321 | |永久错误|应用程序错误无效的节点组id  | +------------+----------------------+-----------------+----------------------+ 1行集(0.00秒)

刚刚显示的查询提供了与通过发出查询获得的信息相同的信息ndb_perror 321或者(现在已弃用)Perror——ndb 321在命令行上。(Bug #86295, Bug #26048272)

ThreadConfig现在有一个额外的nosend参数，该参数可用于防止主要，ldm，代表,或tc通过为给定线程将此参数设置为1，来帮助发送线程。默认情况下,nosend是0。它不能用于刚才列出的线程类型以外的线程。

的所有实例作为推入连接执行扫描时DBSPJ参与单个查询的执行;其中一些查询收到了来自同一查询的多个请求。通过启用单个SPJ请求来处理一组要扫描的根片段，这种情况得到了改善，这样就只向每个根片段发送单个SPJ请求DBSPJ每个节点上的实例和批大小分配给每个片段，多片段扫描可以获得更大的总批大小，允许在其中进行一些调度优化DBSPJ，它可以一次扫描单个片段(给它总的批大小分配)，使用更小的子批并行扫描所有片段，或两者的某种组合。

由于这种更改的效果通常是需要更少的SPJ请求和实例，因此下推连接的性能在许多情况下应该得到改进。

作为正在进行的通过ndbmtd优化批量DDL性能的工作的一部分，现在可以通过增加DDL操作的批量数据部分的批处理大小来获得性能改进，这些DDL操作使用扫描处理一个片段或一组片段中的所有数据。通过设置下面列出的数据节点配置参数，批处理大小现在可以对唯一索引构建、外键构建和在线重组进行配置:

对于刚刚列出的每个参数，默认值为64，最小值为16，最大值为512。

增加适当的批处理大小可以帮助分摊线程间和节点间的延迟，并利用更多的并行资源(本地和远程)来帮助扩展DDL性能。

以前是数据节点LGMAN内核块串行处理undo日志记录;这是并行的。的代表线程，它将撤消记录传递给本地数据处理程序(LDM)线程，在获取下一个记录之前等待LDM完成应用记录;现在,代表线程不再等待，而是立即进行下一个记录和LDM。

与这项工作直接相关的功能上没有用户可见的变化;这个性能增强是NDB 7.6中改进部分局部检查点的撤销长处理的一部分。

当应用undo日志时，表ID和片段ID从页面ID中获取。这是通过读取页面完成的PGMAN使用额外的PGMAN工作线程，但是当应用undo日志时，需要再次读取页面。

这在使用时变得非常低效O_DIRECT(见ODirect)，因为页面没有缓存到OS内核中。

从页ID到表ID和片段ID的映射现在是使用区段标头包含的关于给定区段中使用的页的表ID和片段ID的信息来完成的。由于区段页始终存在于页缓存中，所以执行映射不需要额外的磁盘读取，并且可以使用现有的信息读取TSMAN数据结构。

添加了NODELOG调试命令在ndb_mgm客户端提供对数据节点调试日志记录的运行时控制。开启节点调试导致数据节点向其节点日志写入额外的调试信息，就像节点已被启动一样——详细．关闭节点调试禁用额外的日志记录。

添加了LocationDomainId管理节点、数据节点和API节点的配置参数。在云环境中使用NDB集群时，可通过设置该参数将节点分配给指定的可用域或可用分区。这可以通过以下方式提高性能:

该参数接受0到16之间的整数值，其中0为默认值;使用0与离开相同LocationDomainId未设置的。

重要的变化:的——密码选择ndb_top现在已弃用。它被删除(并替换为——密码)在NDB 7.6.5中。(Bug #88236, Bug #20733646)

参考文献:参见Bug #86615, Bug #26236320, Bug #26907833。

NDB盘数据:一个ALTER TABLE它切换了表的存储格式内存而且磁盘总是在所有列的位置执行。对于存储格式从表继承的列，这是不正确的;列的存储类型没有更改。

例如，该语句创建一个表t1的列c2使用内存存储，因为表隐式这样做:

CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 INT)

的ALTER TABLE语句将导致c2被存储到磁盘上，但未能这样做:

修改表1表空间ts1

类似地，从它所属的表继承其存储格式的磁盘上列的格式不会被更改修改表…存储记忆．

这两种情况现在作为复制alter执行，受影响列的存储格式现在更改了。(错误# 26764270)

解析错误NDB_TABLE修饰符可能导致内存泄漏。(错误# 26724559)

添加转储代码7027，以方便测试与本地检查点有关的问题。有关更多信息，请参见转储7027．(错误# 26661468)

以前的一个补丁旨在改进事务协调器中节点故障处理的日志记录，其中包括在正常操作中可能发生的事务的日志记录，这使得生成的日志不必要地冗长。在这种情况下，此类正常事务不再写入日志。(错误# 26568782)

这个问题是Bug #26364729的回归。

由于配置文件错误，在Linux平台的构建中无法使用CPU锁定功能。(错误# 26378589)

一些转储用于LGMAN内核块在用于属于的代码的范围内被错误地分配了数字DBTUX．现在已经为它们分配了适当范围内的符号常量和数字(10001、10002和10003)。(错误# 26365433)

中的节点故障处理DBTC内核块由许多并发执行的任务组成，所有这些任务必须在TC节点故障处理完成之前完成。此修复扩展了日志记录覆盖范围，以记录每个任务何时完成，以及哪些任务仍然存在，包括以下改进:

(错误# 26364729)

在重启过程中，DBLQH从一个或多个重做日志文件为它所管理的每个重做日志部分加载重做日志部分元数据。由于每个文件的元数据容量都是有限的，因此必须查询的文件数量取决于重做日志部分的大小。这些文件是按顺序打开、读取和关闭的，但是关闭一个文件与打开下一个文件同时发生。

在文件关闭很慢的情况下，每个重做日志部分可以同时打开4个以上的文件;因为这些文件是用OM_WRITE_BUFFER选项，在这种情况下，每个部件分配了超过4个写缓冲区块。写缓冲池不是无限的;如果所有重做日志部件状态相似，则重做日志池已耗尽，导致数据节点关闭。

这个问题可以通过避免使用OM_WRITE_BUFFER在元数据重新加载期间，每个日志文件部分瞬时打开超过4个重做日志文件不再导致数据节点失败。(错误# 25965370)

后截断表在一个NDB表,其AUTO_INCREMENT没有在不执行二进制日志记录的SQL节点上重置ID。(错误# 14845851)

完全位于半连接的物化部分内的连接没有被推入，即使它可以被推入。此外,解释没有提供关于为什么没有推送连接的信息。(Bug #88224, Bug #27022925)

参考文献:参见:Bug #27067538。

当重复清除算法用于计算半连接时，结果中有缺失的行。(Bug #88117, Bug #26984919)

参考文献:参见Bug #87992, Bug #26926666。

松散扫描中使用的表可能被用作推送连接查询中的子表，从而可能导致不正确的结果。(Bug #87992, Bug #26926666)

当在查询计划中表示物化半连接时，MySQL优化器会插入额外的内容QEP_TAB而且JOIN_TAB对象，表示对物化子查询结果的访问。联接下推分析程序没有正确地为它们设置内部数据结构，因此没有初始化它们。这意味着以后使用引用物化半连接的任何项对象时都将访问初始化的tableno列时访问64位tableno位掩码，可能指的是超出其结束的点，这会导致SQL节点的计划外关闭。(Bug #87971, Bug #26919289)

在某些情况下，aSCAN_FRAGCONF接收到信号后SCAN_FRAGREQ已经发送了关闭标志，清除了计时器。当这个发生时，下一个SCAN_FRAGREF到达导致时间跟踪失败。在这种情况下，将在处理SCAN_FRAGREF消息。(Bug #87942, Bug #26908347)

中删除元素时Dbacc，或在哈希表扩展或缩减期间移动它，使用的方法(getLastAndRemove ())可以返回对已发布页面上已删除元素的引用，稍后可以从调用它的函数中引用该元素。这是由于在NDB 7.6.2中实现动态索引内存所带来的变化;以前，这个页面总是属于一个人Dbacc所以访问它是安全的。改变之后，情况就不再是这样了;在Dbacc可以直接放在全局页池中，任何其他线程都可以分配它。

现在我们确保新发布的页面Dbacc保持在水流内Dbacc实例，而不是直接交给全局页池。此外，对已发布页面的引用已被删除;受影响的内部方法现在按值返回最后一个元素，而不是按引用。(Bug #87932, Bug #26906640)

参考文献:参见Bug #87987, Bug #26925595。

的DBTC内核块可以接收一个TCRELEASEREQ处于未准备状态的信号。在这种情况下，它的反应是aTCRELEASECONF消息，随后的行为就像API连接失败了一样。(Bug #87838, Bug #26847666)

参考文献:参见Bug #20981491。

当一个数据节点被配置为将线程锁定到cpu时，它在启动时失败tid锁定失败．

这是修复前一个问题的副作用，该问题基于可用的版本禁用CPU锁定glibc．具体的glibc只有在响应内部NDB API调用(Ndb_UnlockCPU ())不被数据节点使用(并且只能通过内部API调用访问)。当前的修复程序为数据节点启用CPU锁定，并仅对受影响的相关API调用禁用CPU锁定glibc选择“版本”。(Bug #87683, Bug #26758939)

这个问题是一个Bug #86892, Bug #26378589的回归。

ndb_top未能在平台上构建ncurses库没有定义stdscr．现在这些平台需要tinfo库包含在内。(Bug #87185, Bug #26524441)

在本地检查点完成时，每个节点发送一个LCP_COMPLETE_REP向集群中的每个其他节点发送信号;一个节点在收到所有其他节点已发送此信号的通知之前，不会认为LCP已经完成。由于LCP协议中的一个小缺陷，如果该消息从主节点以外的另一个节点延迟，则有可能在一个或多个节点完成正在进行的一个LCP之前启动下一个LCP;这导致了以下问题LCP_COMPLETE_REP来自以前LCP的信号与来自当前LCP的信号混在一起，进而导致节点故障。

为了解决这个问题，我们现在确保在响应任何LCP之前完成前面的LCPTCGETOPSIZEREQ信号发起一个新的LCP。(Bug #87184, Bug #26524096)

使用构建时，NDB集群没有编译成功WITH_UNIT_TESTS =了．(Bug #86881, Bug #26375985)

使用的本地检查点处理的最近改进OM_CREATE打开文件在Windows平台上无法正常工作，系统试图创建一个新文件，如果它已经存在，则会失败。(Bug #86776, Bug #26321303)

一个潜在的百倍信号扇出时，发送START_FRAG_REQ信号可能导致节点故障作业缓冲区已满在重新启动期间尝试执行本地检查点时，启动阶段5出错。(Bug #86675, Bug #26263397)

参考文献:参见Bug #26288247, Bug #26279522。

使用NDB集群时编译失败-DWITHOUT_SERVER = 1只构建客户端库。(Bug #85524, Bug #25741111)

的NDBFS块的OM_SYNC标志的目的是确保用于给定文件的所有FSWRITEREQ信号是同步的，但不支持的平台忽略了它O_SYNC这意味着该功能在这些平台上无法正常运行。现在在那些不支持的平台上使用同步标志O_SYNC．(Bug #76975, Bug #21049554)