重要的变化;包装:为MySQL NDB集群提供的rpm的命名和组织已经更改，以与MySQL服务器发布的rpm保持一致。所有MySQL NDB集群RPM包的名称现在都有前缀mysql-cluster．方法安装数据节点数据节点包;管理节点现在从管理服务器包;和SQL节点需要服务器而且常见的包。重要的: SQL节点必须使用mysql-cluster这些rpm的版本;标准MySQL服务器发布的版本不支持NDB存储引擎。所有客户端程序，包括mysql客户与ndb_mgm管理客户端，现在包含在客户端RPM。

有关更多信息，请参见从RPM安装NDB集群．

重要的变化:添加了PARTITION_BALANCE值FOR_RA_BY_LDM_X_2，FOR_RA_BY_LDM_X_3,FOR_RA_BY_LDM_X_4，它可用于将每个本地数据管理器使用的分区数量分别设置为两个、三个和四个分区FOR_RA_BY_LDM，这将把这个数字设置为1。

使用MAX_ROWS设置所使用的分区数NDB表现在已弃用，并将在未来的MySQL NDB集群版本中删除。

有关更多信息，请参见设置NDB_TABLE选项．(Bug #81759, Bug #23544301)

添加了——print-sql-log选项。ndb_restore程序包含在MySQL NDB集群发行版中。该选项使程序将SQL语句记录到stdout．

注意，以这种方式恢复的每个表必须有一个显式定义的主键;方法实现的隐藏主键NDB存储引擎为不足以达到此目的。(错误# 13511949)

对于完全复制的表，ndb_desc仅显示持有分区主片段副本的节点;仅具有复制片段副本的节点将被忽略。使此信息可在mysql客户端中引入了几个新表ndbinfo信息数据库。下面列出了这些表格，并附有简要说明:

有关更多信息，请参见ndbinfo: NDB集群信息数据库．(Bug #81762, Bug #23547643)

重要的变化:的默认值——ndb-default-column-format服务器选项已更改为动态来固定．这样做是为了向后兼容。只有默认值被改变了;将此选项设置为动态继续造成动态用于…ROW_FORMAT而且COLUMN_FORMAT除非覆盖。(错误# 24487363)

重要的变化:事件缓冲区状态报告通过更改计算延迟或滑移的语义得到了改进。现在，我们不再将延迟定义为延迟的epoch数，而是将其视为事件缓冲区中完全缓冲、但尚未被binlog注入器线程消耗的epoch数。的默认值作为该工作的一部分ndb_report_thresh_binlog_epoch_slip系统变量从3增加到10。有关更多信息，请参见文档中对该变量的描述10bet官方网站集群日志中的事件缓冲区报告．(错误# 22916457)

参考文献:参见Bug #22901309。

NDB集群接口:事务id的重用可能发生在Ndb同时创建和删除对象。作为此修复的一部分，NDB API方法lock_ndb_objects ()而且unlock_ndb_objects现在被宣布为常量．(错误# 23709232)

NDB集群接口:当管理服务器在运行持续监视事件的MGM API应用程序时重新启动，后续事件不会报告给应用程序，超时将无限返回，而不是错误。

这是因为重新启动时事件监听器的套接字没有关闭mgmd．这可以通过确保在管理服务器关闭时关闭事件监听器套接字来解决，这会导致应用程序使用诸如ndb_logevent_get_next ()在重新启动后收到读错误。(错误# 19474782)

NDB集群接口:要处理传入的信号，想要充当接收器的线程必须从传输层获得轮询权限。这可以请求并分配给单独的接收线程，或者每个客户端线程在等待结果时都可以担任接收方角色。

当充当轮询所有者的线程接收到足够数量的数据时，它在向其他客户端发送信号时释放对它们的锁。这可以使它们再次可运行，操作系统调度器可以决定是时候唤醒它们了，这是以牺牲轮询所有者线程为代价的，这些线程反过来被排除在CPU之外，但仍然在CPU上拥有轮询权限。在此修复之后，轮询权限在解锁和发送信号给其他线程之前由线程释放。这使得在此CPU上积极执行的其他线程可以使用轮询权限。

当轮询接收方数据时，此更改增加了并发性，这也应该减少等待唤醒的客户机的延迟。(Bug #83129, Bug #24716756)

NDB集群接口:libndbclient而且libmysqlclient导出冲突的符号，导致在Linux上的调试构建中出现分割错误。为了解决这个问题，在libndbclient.so不再公开露面。的版本号libndbclient.so已从6.0.0提升到6.1.0。(Bug #83093, Bug #24707521)

参考文献:参见Bug #80352, Bug #22722555。

NDB集群接口:当NDB模式对象所有权检查由NdbTransaction，此事务使用的对象将被检查，以确保它们属于NdbDictionary属于这个关系。试图创造一个NdbOperation，NdbScanOperation,或NdbIndexScanOperation在不属于同一连接的表或索引上失败。

此补丁纠正了一个资源泄漏，该资源泄漏是在检查模式对象所有权之前分配要创建的操作对象，随后在对象创建失败时未释放。(Bug #81949, Bug #23623978)

参考文献:参见Bug #81945, Bug #23623251。

NDB集群接口:对象的上下文中分配NDB API对象Ndb对象，或指NdbTransaction对象拥有的对象Ndb对象。当给定的Ndb对象被摧毁，所有剩余NdbTransaction对象被终止，所有与此相关的NDB API对象Ndb对象也应该在此时释放。当NdbTransaction对象的父对象Ndb对象已销毁，从对象分配的泄漏NdbTransaction可能会出现对象。(然而,NdbTransaction对象本身不会泄漏。)

虽然这是明智的(事实上，建议)关闭一个NdbTransaction明确地说，一旦它的生命周期结束，父进程就会被销毁Ndb对象应该足以释放依赖于它的任何对象。在之前描述过的情况下Ndb析构函数进行检查，以确保所有对象都派生自给定的Ndb实例被真正释放。(Bug #81945, Bug #23623251)

NDB集群接口:这个词”片段计数类型”已经被”分区平衡”．这个变化影响NDB_TABLE选项NDB表以及NDB API。在NDB_TABLE表选项语法FRAGMENT_COUNT_TYPE关键字替换为PARTITION_BALANCE．在NDB API中表格方法getFragmentCountType ()而且setFragmentCountType ()已改名为getPartitionBalance ()而且setPartitionBalance ()分别;getFragmentCountTypeString ()重命名为getPartitionBalanceString ()．此外,对象:FragmentCountType已改名为PartitionBalance，其枚举值的名称已更新为与新的命名法一致。

有关这些更改如何影响NDB API应用程序的更多信息，请参见所示的表格而且对象成员的描述。有关作为此修复的一部分所做的sql级更改的更多信息，请参阅设置NDB_TABLE选项．(Bug #81761, Bug #23547525)

参考文献:参见Bug #83147, Bug #24733331。

NDB集群接口:在MySQL NDB集群发行版中包含的一些NDB API示例程序中，ndb_end ()在调用Ndb_cluster_connection析构函数。这导致在所有平台上的调试构建中出现分割错误。受影响的示例程序也经过了广泛的修订和重构。看到NDB API示例，以查询更多资料。(Bug #80352, Bug #22722555)

参考文献:参见Bug #83093, Bug #24707521。

如果计算内部函数时超过4096秒NdbDuration: microSec ()值，这可能导致断言警告，表示计算将溢出。我们修复这个，以避免从内部转换时任何溢出或精度损失”蜱虫”格式化为微秒和纳秒，具体方法是在对应秒和几分之一秒的两个部分执行计算。(错误# 24695026)

串行提交协议——该协议在每个副本上分别串行地提交每个操作，并由DBTC内核块(请参阅DBTC块)进行接管，以及当交易被判定在接管期间已超时时提交或完整的相位没有支持LATE_COMMIT,这是需要的READ_BACKUP而且FULLY_REPLICATED协议。(错误# 24681305)

在某些情况下，修改表…重组分区可能导致集群意外关闭。这是因为，对于完全复制的表。假设日志部件ID与分区ID相同。当这种方法奏效时FOR_RA_BY_LDM，但不一定用于其他分区平衡类型。(错误# 24610551)

使用算法=原地在更换任何一张桌子的时候NDB_TABLE属性(见设置NDB_TABLE选项)导致服务器失败。(错误# 24584741)

后连续ALTER TABLE报表更新NDB_TABLE属性(见设置NDB_TABLE选项)，当前值并不总是显示显示创建表或ndb_desc．(错误# 24584690)

关键字不区分大小写，如FULLY_REPLICATED在NDB_TABLE评论未获尊重。(错误# 24577931)

一个ALTER TABLE语句试图设置两者FULLY_REPLICATED而且PARTITION_BALANCE(见设置NDB_TABLE选项)失败，显示错误信息。(错误# 24577894)

binlog注入器线程和NDB实用程序线程——同步和其他问题的循环来源——被删除了。主要的变化如下:

(错误# 24496910)

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

延迟提交消信号用于FULLY_REPLICATED或READ_BACKUP导致相关的ApiConnectionRecord无效的状态(错误# 24459817)

参考文献:参见Bug #24444861。

为磁盘上的表满时发生的失败添加了缺失的错误信息。(错误# 24425373)

当ndbmtd崩溃时，产生的错误日志错误地指定了线程0的跟踪名称，附加了不存在的后缀_t0到文件名。(错误# 24353408)

传递不存在的节点ID创建节点组导致随机数据节点故障。(错误# 23748958)

删除表随之而来的是节点关闭和随后的主接管，并且在接管之前包含本地检查点还没有完成，这会导致LCP被忽略，在某些情况下，数据节点会失败。(错误# 23735996)

参考文献:参见Bug #23288252。

删除了一个无效断言，即在主事务终止后API连接记录释放时关闭所有级联子扫描。断言是无效的，因为在这种情况下，扫描的关闭在设计上与主事务是异步的，这意味着在主事务关闭后，子扫描可能需要一些时间来关闭。(错误# 23709284)

尽管对转储命令是32位整数，ndb_mgmd在处理它们时只使用了10字节的缓冲区。(错误# 23708039)

的READ_BACKUP在执行扫描时，设置不受尊重团表。(错误# 23703536)

设置FULLY_REPLICATED = 1(见设置NDB_TABLE选项)没有传播到内部团用于团而且文本列。(错误# 23703343)

的READ_BACKUP设置未应用于惟一索引。(错误# 23702848)

在ReadCommitted模式,DBSPJ读取表的主片段副本READ_BACKUP(见设置NDB_TABLE选项)，即使本地片段是可用的。(错误# 23633848)

所有报告内存使用情况在使用完全复制表时产生不正确的输出。(错误# 23539805)

有序索引没有继承READ_BACKUP(见设置NDB_TABLE选项)，这意味着有序的索引扫描继续只被路由到主片段副本，而不会被路由到备份片段副本。

现在DBDICT的实例分发此信息时，在表属性的有序索引上设置此属性DBTC而且DBSPJ．(错误# 23522027)

对包含虚拟列的表的更新可能导致二进制日志记录线程失败。(错误# 23514050)

中发现并修复了一些潜在的缓冲区溢出问题NDB代码库。(错误# 23152979)

在从MySQL NDB Cluster 7.3版本在线升级到NDB 7.4(或更高版本)的过程中，在本地检查点(lcp)期间，以及升级这些节点之前，运行较低版本的几个数据节点发生了故障，导致升级之后出现了其他节点故障。这是由于残留的元素EMPTY_LCP协议由旧节点发起，作为LCP +重启序列的一部分，由于在这些版本中实现了LCP优化，该协议在NDB 7.4及以后的版本中不再使用。(错误# 23129433)

一个SIGNAL_DROPPED_REP类中定义了为响应长消息缓冲区耗尽而调用的处理程序SPJ内核块，但实际上没有使用。这意味着来自的默认处理程序SimulatedBlock在这种情况下使用，这会关闭数据节点。(错误# 23048816)

参考文献:参见Bug #23251145, Bug #23251423。

在系统重启过程中，当一个数据节点的重做缓冲区不足时，它不会参与重启，直到其他节点启动后。在此之后，它从已经启动的节点组中的节点中接管它的片段;在此期间，集群已经在运行，可以进行用户活动，包括DML和DDL操作。

在系统重新启动期间，表创建在DIH内核块，因为这个创建实际上包括从主节点上的磁盘重新加载表定义数据。因此,DIH假设在所有节点重新启动之前发生的任何表创建都必须与重新启动相关，因此总是在主节点上。然而，在接管期间，由于用户活动，表的创建可能发生在非主节点上;当这种情况发生时，集群将被迫关闭。

现在，在系统重新启动期间进行额外检查，以检测在这种情况下执行节点是否是主节点，并使用该信息确定表创建是重新启动的一部分，还是在后续接管期间进行的。(错误# 23028418)

ndb_restore设置MAX_ROWS属性的值，在执行备份之前未为其设置。(错误# 22904640)

每当数据节点被添加到或从集群中删除时，NDB内核的事件API使用SUB_GCP_COMPLETE_REP信号用添加(添加)标志或子(丢弃)标志设置，以及添加或丢弃的节点数量;这允许NDB保持…的正确计数SUB_GCP_COMPLETE_REP每个未完成桶的挂起信号。除了为与添加或删除相关的epoch处理桶之外，它还必须补偿与之后的epoch相关的任何后来不完整的桶。尽管可以随意完成这些桶，但没有处理这些桶，导致一个摊位进入活动接待处。

这个修复增加了检测和处理这种乱序的桶完成。(错误# 20402364)

参考文献:参见Bug #82424, Bug #24399450。

在执行表的在线重组时，重组中不包含惟一索引。(错误# 13714258)

在非常高的负载下，接收线程和任何用户线程都没有足够的能力正确处理轮询所有权。这意味着，随着负载和活动线程数量的增加，维持吞吐量变得更加困难。此修复程序尝试增加接收线程的优先级，并在成功时保留轮询所有权。

此修复程序需要足够的权限才能启用。在Linux系统上，这意味着确保数据节点二进制文件或作为其运行的用户具有更改nice级别的权限。(Bug #83217, Bug #24761073)

当从包含具有外键的表的数据库恢复备份时，ndb_restore为数据禁用外键，但没有为日志禁用外键。(Bug #83155, Bug #24736950)

对于使用多个节点组的完全复制表，唯一索引表和blob表的本地读取不能正确工作。(Bug #83016, Bug #24675602)

的影响ALTER TABLE语句更改要使用的表READ_BACKUP群集重新启动后未保留。(Bug #82812, Bug #24570439)

使用FOR_RP_BY_NODE或FOR_RP_BY_LDM为PARTITION_BALANCE不能使用完全复制的表。(Bug #82801, Bug #24565265)

更改READ_BACKUP设置没有传播到内部blob表。(Bug #82788, Bug #24558232)

控件显示的计数c_exec列中的ndbinfo.threadstat表格不完整。(Bug #82635, Bug #24482218)

默认的PARTITION_BALANCE设置NDB创建的表READ_BACKUP = 1(见设置NDB_TABLE选项)已由FOR_RA_BY_LDM来FOR_RP_BY_LDM．(Bug #82634, Bug #24482114)

内部函数ndbcluster_binlog_wait ()，它提供了一种方法，以确保源自给定线程的所有事件都到达二进制日志中显示binlog事件以及重置二进制日志时。该函数在处理最新的全局epoch时，等待注入器条件NDB比此会话中最后提交的epoch更近，这意味着每当二进制日志线程完成并更新一个新的最新全局epoch时，就必须发出此条件的信号。对代码的检查显示，这个条件信号缺失，并且，当一个新的最新全局历完成时(~100ms)，客户机线程不会被唤醒，而是等待最大超时(1秒)。

此修复增加了注入器条件信号的缺失，同时将其更改为条件广播，以确保所有客户端线程都收到警报。(Bug #82630, Bug #24481551)

完全复制的内部外键或惟一索引触发器可能触发多次，这将导致插入或删除操作的事务中止。这是由于在预提交期间触发了冗余的延迟约束触发器。现在，在这种情况下，我们确保在此阶段只触发特定于唯一索引的触发器。(Bug #82570, Bug #24454378)

在使用完全复制表时，由于内部触发器资源的大量使用(以及随后的耗尽)，备份可能会失败。为弥补这一点，在NDB内核内部触发器已经增加，现在部分基于表的最大数量。(Bug #82569, Bug #24454262)

参考文献:参见Bug #23539733。

在DBTC函数executeFullyReplicatedTrigger ()在NDB内核中，错误的状态检查在某些情况下导致在实际没有发生故障的情况下进行故障处理。(Bug #82568, Bug #24454093)

参考文献:参见Bug #23539733。

回程时LQHKEYREQ失败了LQHKEYREF在内部触发器操作中，不会检查触发器是否被完全复制，因此那些被完全复制的触发器永远不会被处理。(Bug #82566, Bug #24453949)

参考文献:参见Bug #23539733。

当READ_BACKUP之前没有设置，那么就设置为1作为一个修改表…算法=原地语句，则未将更改传播到内部惟一索引表或团表。(Bug #82491, Bug #24424459)

MySQL权限分配不完整，原因是mysql_cluster_move_privileges ()过程将mysql.proxies_priv表NDB．这一切的根本原因是修改表…引擎NDB语句，当该表包含非法时，该语句有时会失败时间戳值。(Bug #82464, Bug #24430209)

内部变量m_max_warning_level未初始化存储/ ndb / src /内核/块/ thrman.cpp．当未初始化的值被视为0时，这有时会导致重新启动期间的节点故障。(Bug #82053, Bug #23717703)

通常，在执行系统重启时，从重做日志和本地检查点(lcp)恢复所有节点，但在某些情况下，一些节点可能需要一个复制阶段，然后才能完成系统重启。当发生这种情况时，相关节点将等待所有其他节点完全启动，然后再执行复制阶段。的开始阶段4之前就可以开始一个本地检查点DBDIH日志含义LCP状态初始化为闲置在所有情况下，这都可能导致节点故障。现在，当执行这种系统重新启动的变体时，LCP状态不再初始化。(Bug #82050, Bug #23717479)

在在线添加新节点组并执行之后修改表…算法= inplace重组分区，新片段的分区id没有正确设置。

在解决这个问题的相关更改中，ndb_desc- p现在按分区ID的顺序显示与分区相关的行。(Bug #82037, Bug #23710999)

在执行停止备份有时，在备份进程实际终止之前，可能会向备份数据文件写入几个字节。当使用ODIRECT，这将导致返回错误的错误代码。在这种情况下，什么也不写O_DIRECT文件，除非对齐正确。(Bug #82017, Bug #23701911)

当事务协调器(TC)连接记录用完时，可以只处理本地检查点和备份的扫描，因此来自DBUTILblock-used为修改表…重组分区以及其他重组元数据的操作——都被不必要地阻塞了。此外，当TC记录耗尽时，这类操作并不总是被重试。为了解决这个问题，现在指定了一些操作记录DBUTIL使用，以及LCP和备份使用，以便这些操作也不会受到来自的操作的负面影响DBUTIL．

有关更多信息，请参见DBUTIL块．(Bug #81992, Bug #23642198)

在同一个事务中对同一行执行多次更新的操作有时会导致页面条目长度的损坏。(Bug #81938, Bug #23619031)

在节点重启期间，片段可以使用从本地检查点(lcp)获得的信息进行恢复;在任何给定时间内最多保留2个可恢复lcp。当LCP报告给DIH内核块已经完成，但是在最后一个写入LCP的全局检查点索引实际完成之前节点失败，那么最新的LCP是不可恢复的。尽管应该可以使用旧的LCP，但相反，它假定片段不存在LCP，这减慢了重新启动过程。现在，在这种情况下，使用旧的、可恢复的LCP，这应该有助于减少较长的节点重启时间。(Bug #81894, Bug #23602217)

优化的节点选择(ndb_optimized_node_selection布景)不被尊重ndb_data_node_neighbour当它被启用时。(Bug #81778, Bug #23555834)

NDB如果由于超时(默认为3000ms)而失败，并且此锁请求有可能参与元数据锁-全局模式锁死锁，则不再重试全局模式锁。在这种情况下，它选择自己作为”受害者”，并将决策返回给元数据锁的请求者，然后将该请求作为失败的锁请求处理(最好是无限期地保持死锁状态)，或者，如果存在死锁处理程序，则重试元数据锁全局模式锁。(Bug #81775, Bug #23553267)

在哈希映射的实现中发现了两个问题NDB将表行的哈希值映射到分区—对于完全复制的表:

此修复程序解决了刚才描述的两个问题。(Bug #81757, Bug #23544220)

参考文献:参见Bug #81761, Bug #23547525, Bug #23553996。

使用mysqld在一起——初始化而且——ndbcluster导致后来在尝试使用时出现问题mysql_upgrade．跑步时——初始化，服务器不需要NDB支持，并且启用它会导致与ndbinfo表。要防止这种情况发生，可以使用——初始化选项现在会导致mysqld忽略——ndbcluster选项，如果还指定了后者。

此问题只影响从MySQL NDB Cluster 7.5.2或7.5.3升级。如果由于前面列出的原因导致升级失败，您可以通过删除所有升级来解决这个问题.frm的文件数据/ ndbinfo目录，然后滚动重新启动整个集群，然后运行mysql_upgrade．(Bug #81689, Bug #23518923)

参考文献:参见Bug #82724, Bug #24521927。

而一个mysqld的初始化过程中等待连接到管理服务器NDBHandler，我们不可能关闭mysqld．如果mysqld无法建立连接，它可能会在这里卡住。这是由于实用程序和索引统计线程中的内部等待条件可能无限期地无法满足。这个条件已经增加了1秒的最大超时，这使得这些线程在这种情况下更有可能正确地终止自己。

此外，在刚刚描述的情况下，等待管理服务器连接的连接线程执行了2次睡眠，而不是预期的1次睡眠。(Bug #81585, Bug #23343673)

修改表…算法=原地中没有复制相关的触发器ID，从而导致DBDICT内核块。(Bug #81544, Bug #23330359)

对象准备中止时创建的延迟树节点查找请求的列表DBSPJ请求完成时未被清除，这可能导致即使在DBSPJ请求中止。(Bug #81355, Bug #23251423)

参考文献:参见Bug #23048816。

中的错误和中止处理Dbspj: execTRANSID_AI ()是这样实施的abort ()方法在完成对传入信号的处理之前调用。由于此方法向LDM发送信号，这部分覆盖了信号的内容execTRANSID_AI ()．这可能导致流产DBSPJ请求过早地清理其分配的资源，或者根本不清理。(Bug #81353, Bug #23251145)

参考文献:参见Bug #23048816。

在MySQL NDB Cluster 7.5.2中添加的读备份特性使从备份片段副本中读取成为可能，但没有用于带锁的读取或对的读取团表或唯一键表，其中锁升级为带锁读取。现在,TCKEYREQ而且SCAN_TABREQ信号使用标志来传递关于此类锁的信息，使得当读锁由于是BLOB表的基表的读或由于是唯一键的读而升级时，可以从备份片段副本中读取。(Bug #80861, Bug #23001841)

分区表的主片段副本没有均匀地分布在节点组和本地数据管理器中。

作为修复这个问题的一部分，单个MySQL NDB集群支持的最大节点组数量，以前没有确定，现在设置为48 (MAX_NDB_NODE_GROUPS)．(Bug #80845, Bug #22996305)

中的几个对象构造函数和类似函数NDB代码库在创建新实例时并不总是执行健全检查。这些检查现在是在这种情况下进行的。(Bug #77408, Bug #21286722)

内部呼叫malloc ()没有检查零．函数调用被直接写入替换。(Bug #77375, Bug #21271194)