重要的变化:在此之前,ndbinfo信息数据库包括使用MyISAM存储引擎。这种依赖MyISAM现在已经被移除。(错误# 20075747)

重要的变化:在此之前,NDB调度器总是以预定的方式针对吞吐量优化速度(这是硬编码的);该余额现在可以使用SchedulerResponsiveness数据节点配置参数。该参数接受0-10范围内的整数，默认值为5。相对于吞吐量，较高的值提供更好的响应时间。较低的值提供了较高的吞吐量，但增加了较长的响应时间。(Bug #78531, Bug #21889312)

重要的变化:许多MySQL NDB集群数据节点配置参数在早期版本的MySQL NDB集群中已弃用，并已在此版本中删除。这些参数包括Id，NoOfDiskPagesToDiskDuringRestartTUP，NoOfDiskPagesToDiskDuringRestartACC，NoOfDiskPagesToDiskAfterRestartACC，NoOfDiskPagesToDiskAfterRestartTUP，ReservedSendBufferMemory，MaxNoOfIndexes,Discless(使用无盘相反)，以及DiskCheckpointSpeed而且DiskCheckpointSpeedInRestart．过时的和未使用的ByteOrder计算机配置参数也被删除，以及未使用的MaxNoOfSavedEvents管理节点配置参数。这些参数不再受支持;其中大多数已经没有(或不再有)任何影响。尝试在MySQL NDB集群配置文件中使用这些参数中的任何一个都会导致错误。

有关更多信息，请参见新db集群7.5有什么新内容．(Bug #77404, Bug #21280428)

重要的变化:的ndbinfo数据库现在可以提供MySQL NDB集群节点配置参数的默认和当前信息，这是以下变化的结果:

您可以通过名称在这两个表上使用连接来获取MySQL NDB集群配置参数的值，如下所示:

SELECT p.param_name AS名，v.node_id AS节点，p.param_type AS类型，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');

(Bug #71587, Bug #18183958)

重要的变化:的ExecuteOnComputer管理节点、数据节点和API节点的配置参数现在已弃用，并将在未来的MySQL NDB集群版本中删除。对于所有类型的MySQL NDB集群节点，您现在应该使用主机名用于在集群配置文件中标识主机的专用参数。

的输出中也显示此信息ndb_config——configinfo——xml．(Bug #53052, Bug #11760628)

已弃用的MySQL NDB集群节点配置参数现在指示为ndb_config——configinfo——xml．对于当前已弃用的每个参数，对应的< param / >标记中的XML输出现在包含属性弃用= " true "．(错误# 21127135)

添加了——ndb-cluster-connection-pool-nodeids选择mysqld，它可用于按节点ID指定用于连接池的节点列表。列表中节点id的个数必须等于设置的值——ndb-cluster-connection-pool．(错误# 19521789)

添加了提示命令的ndb_mgm客户端。该命令的语法提示字符串，它将客户端的提示设置为字符串．发出不带参数的命令将导致提示符重置为默认值(ndb_mgm >)．看到NDB集群管理客户端命令，以查询更多资料。(错误# 18421338)

当——数据库选项未指定ndb_show_tables中没有找到表TEST_DB数据库，一个适当的警告消息现在发出。(Bug #50633, Bug #11758430)

的NDB存储引擎现在使用改进的每键记录接口来进行索引统计，这是在MySQL 5.7中为优化器引入的。下面列出了一些改进:

不兼容的更改;NDB集群api:的pollEvents2 ()方法现在返回-1，表示错误，只要对time参数使用负值。(错误# 20762291)

重要的变化;NDB集群api:Ndb: pollEvents ()现在与TE_EMPTY，TE_INCONSISTENT,TE_OUT_OF_MEMORYMySQL NDB集群7.4.3中引入了事件类型。有关此更改的详细信息，请参见MySQL NDB集群API开发指南．(错误# 20646496)

重要的变化;NDB集群api:添加的方法Ndb: isExpectingHigherQueuedEpochs ()到NDB API，以检测何时检测到额外的、更新的事件周期pollEvents2 ()．

的行为Ndb: pollEvents ()也修改过，所以现在返回NDB_FAILURE_GCI(等于~ (Uint64) 0)当检测到集群故障时。(错误# 18753887)

重要的变化;NDB集群api:为了释放用于删除事件操作的内存，事件API以前依赖于此pollEvents ()而且nextEvent ()使用可能引用已删除事件的所有事件。之间的依赖关系dropEventOperation ()前两个方法需要在尝试释放事件操作内存之前读取整个事件缓冲区(也就是说，直到连续调用pollEvents ()而且nextEvent ()不再返回事件)。

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

为了解决这些问题，现在在删除最后一个事件操作时清除事件缓冲区，而不是等待可能发生或不发生的后续创建操作。被删除的事件操作占用的内存现在也会在事件队列被清除后释放，这就消除了使用所有事件来释放内存的隐藏需求。此外，事件操作内存现在在引用操作的所有事件都被消耗完后立即释放，而不是等待整个事件缓冲区被消耗。(Bug #78145, Bug #21661297)

重要的变化;NDB集群api:MGM API错误处理函数ndb_mgm_get_latest_error ()，ndb_mgm_get_latest_error_msg (),ndb_mgm_get_latest_error_desc ()当与a一起使用时，每一个都失败了零句柄。您应该注意，尽管这些函数现在是空安全的，但在这种情况下返回的值是任意的，没有意义。(Bug #78130, Bug #21651706)

重要的变化;NDB集群api:以下NDB API方法没有实际实现，已经从源代码中删除:

重要的变化:的选项控制行为NDB与连接到管理服务器的连续尝试的数量和时间有关的程序已经更改，如下所示:

(错误# 22116937)

重要的变化:在以前版本的MySQL NDB Cluster中，其他DDL操作不能被包含修改在线表…重命名…．(这在修复BUG#16021021时被禁止。)MySQL NDB Cluster 7.5进行了以下修改:

(Bug #20804269, Bug #76543, Bug #20479917, Bug #75797)

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

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

NDB集群api:二进制日志注入器没有正确工作TE_INCONSISTENT的事件类型处理Ndb: nextEvent ()．(错误# 22135541)

参考文献:参见Bug #20646496。

NDB集群api:在执行dropEvent ()，如果协调器DBDICT订阅管理器(SUMABlock)已经删除了所有订阅，但在协调器从系统表中删除事件之前，已删除的事件仍保留在表中，导致后续任何同名的删除或创建事件都失败NDB错误1419已经订阅了或错误746事件名称已经存在．即使在调用时也会发生这种情况dropEvent ()用一个非零力参数。

在这种情况下，错误1419会被忽略DBDICT从表中删除事件。(错误# 21554676)

NDB集群api:的创造和毁灭Ndb_cluster_connection多个线程的对象可能会使用相同的应用程序锁，这在某些情况下会导致全局字典缓存失败。为了缓解这个问题，已经序列化了几个内部NDB API对象的创建和销毁。(错误# 20636124)

NDB集群api:当一个Ndb对象被重用，则此对象的事件队列仍可包含发生在故障之前的数据节点事件。这些事件可以参考”老”epoch(从故障发生之前开始)，这反过来又可能违反nextEvent ()方法，使历元数始终增加。在这种情况下，可以通过显式清除事件队列来解决此问题。(错误# 18411034)

参考文献:参见Bug #20888668。

NDB集群api:Ndb: pollEvents ()而且pollEvents2 ()接收事件较慢，依赖于其他客户机线程或块代表它们执行传输器轮询。此修正允许客户端线程在必须在这些方法中等待时执行自己的传输器轮询。

传输轮询的引入还揭示了一个问题，即在ndbcluster_binlog处理程序，该处理程序已作为此修复的一部分添加。(Bug #79311, Bug #20957068, Bug #22224571)

NDB集群api:在集群故障后节点的初始重新启动之后，当重新启动之前存在的事件稍后被删除时，作为重新启动过程一部分添加的集群故障事件将被删除。这意味着，在这种情况下，事件API客户端无法知道是否需要进行故障处理。此外，GCI用于删除事件操作的最终清理，由pollEvents ()而且nextEvent ()当这些方法消耗了所有可用事件时，将丢失。(Bug #78143, Bug #21660947)

MySQL NDB Cluster 7.4.8无意中引入了一个严重的回归，本地检查点和重启的时间通常比预期的要长。这是由于设置为MaxDiskWriteSpeedOwnRestart在重新启动时被忽略，值为MaxDiskWriteSpeedOtherNodeRestart的默认值要比的默认值低得多MaxDiskWriteSpeedOwnRestart改为使用了。此问题只影响重启时间和性能，对正常操作没有任何影响。(错误# 22582233)

集群日志中作为报告的一部分提供的最新可恢复检查点的epochEventBufferStatus事件(见NDB集群:集群日志中的消息)定义不清楚，因此不可靠;根据不同的因素，报告的时代可以是当前正在消耗的时代、最近消耗的时代或下一个排队等待消耗的时代。

此修正确保最新的可恢复全局检查点始终被视为用户最近完全使用的检查点，因此它是生成报告时存在的最新的可恢复全局检查点。(错误# 22378288)

添加了——ndb-allow-copying-alter-table选择mysqld．设置此选项(或等效的系统变量)ndb_allow_copying_alter_table)从保持ALTER TABLE语句从执行复制操作。默认值为在．(错误# 22187649)

参考文献:参见Bug #17400320。

试图创建一个NDB表的宽度大于所有表所支持的最大组合宽度位当用定义列时，列(4096)会导致数据节点故障COLUMN_FORMAT动态．(错误# 21889267)

创建一个表，其中包含最大支持的列数(512)COLUMN_FORMAT动态导致数据节点故障。(错误# 21863798)

在有多个LDM实例的MySQL NDB集群中，所有实例都写入节点日志，即使是其他节点上未激活的实例。在重新启动过程中，这会导致日志被来自其他节点的消息填满，例如如下所示的消息:

2015-06-24 00:20:16 [ndbd] INFO—我们正在调整最大磁盘写速度，一个重启正在进行中…2015-06-24 01:08:02 [ndbd] INFO—我们正在调整最大磁盘写速度，没有重启正在进行中

现在，只由活动LDM实例执行此日志记录。(错误# 21362380)

备份时，备份块状态报告错误。(错误# 21360188)

参考文献:参见Bug #20204854, Bug #21372136。

的暂停GET_TABINFOREQ当执行一个创建索引返回错误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。

以前，可以调用多个发送线程来处理发送到同一个节点的消息;这些线程然后竞争相同的发送锁。当发送锁阻塞额外的发送线程时，工作线程可以被传递到其他节点。

这个问题可以通过确保在已经有活动的发送线程分配给同一节点时没有激活新的发送线程来解决。此外，已经分配了一个活动的发送线程的节点对其他已经活动的发送线程不再可见;也就是说，当发送线程当前分配给该节点时，该节点将不再被添加到节点列表中。(Bug #20954804, Bug #76821)

当重做日志过载时，挂起的操作正在排队(DefaultOperationRedoProblemActionAPI节点配置参数)可能导致超时，当数据节点耗尽重做日志空间(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在使用之前进行测试，以确保已正确设置。(Bug #20575424, Bug #76255)

参考文献:参见Bug #20561446, Bug #21616263。

NDB的错误延迟可以延迟统计信息查询ndb_index_stat_option(默认60秒)当查询的索引被标记为内部错误。同样的潜在问题也可能引起分析表绞死:在对…执行绞刑时被绞死NDB表具有多个索引，其中一个或多个索引上发生了内部错误，但不是所有索引上都发生了内部错误。

现在，在这种情况下，将立即返回任何现有的统计信息，而不等待发现任何额外的统计信息。(Bug #20553313, Bug #20707694, Bug #76325)

在获取表或数据库列表时分配的内存随后没有被释放。(Bug #20234681, Bug #74510)

参考文献:参见Bug #18592390, Bug #72322。

添加了BackupDiskWriteSpeedPct数据节点参数。设置此参数使数据节点保留其最大写速度的百分比(由的值决定)MaxDiskWriteSpeed)，以便在执行备份时在本地检查点使用。BackupDiskWriteSpeedPct被解释为一个百分比，该百分比可以设置在0到90之间(包括90)，默认值为50。(错误# 20204854)

参考文献:参见Bug #21372136。

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

这个问题在mysql客户端，以及当使用Connector/J和其他MySQL api的应用程序执行这些事务时。

在升级之前，这个问题可以通过执行从information_schema中选择table_name, table_schema。engine = ' ndbcluster '的表在执行任何其他语句之前，在恢复操作之后的所有SQL节点上执行。(错误# 18075170)

使用ndb_mgm停止- f为了强制一个节点关闭，即使它触发了集群的完全关闭，当关闭足够数量的节点时，可能会丢失数据，从而触发集群关闭，时间是这样的SUMA已经向已经处于关闭过程中的节点进行了交接。(错误# 17772138)

当使用足够大的值时TransactionDeadlockDetectionTimeout和的默认值sort_buffer_size、执行选择*从ndbinfo.cluster_operationsORDER BY transid如果存在多个并发冲突或死锁事务，每个事务都有几个挂起的操作，则会导致运行查询的SQL节点失败。(Bug #16731538, Bug #67596)

的ndbinfo.config_params表现在是只读的。(Bug #11762750, Bug #55383)

NDB由于设置了当前本地检查点的状态但不是活动的，在节点重启期间失败，尽管在这种条件下它可能有其他状态。(Bug #78780, Bug #21973758)

ndbmtd检查信号是否只有在一个完整周期后才发送run_job_buffers，这将对所有作业缓冲区输入执行。这是run_job_buffers本身，这避免了长时间执行而不发送到其他节点或向其他线程刷新信号。(Bug #78530, Bug #21889088)

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

当发送缓冲区成为限制资源时，可能会导致发送缓冲区互斥锁的结果，这可能是由于发送缓冲区资源配置不足、通信缓慢或失败(导致所有发送缓冲区耗尽)的问题，或者速度较慢的接收方未能消耗所发送的内容。在这种情况下，工作线程无法为信号分配发送缓冲区内存，并试图强制发送以释放空间，而与此同时，发送线程正忙于试图发送到同一个或多个节点。所有这些线程都在竞争获取发送缓冲区互斥锁，这导致了已经描述过的锁，由看门狗报告为在发送．此修复分为以下两部分:

(Bug #77081, Bug #21109605)