MySQL NDB集群7.5.0是MySQL NDB集群7.5的新版本,基于MySQL Server 5.7,包含7.5版本的特性NDB
存储引擎,以及修复最近在以前的NDB集群版本中发现的错误。
获取MySQL NDB 7.5集群。MySQL NDB集群7.5源代码和二进制文件可以从10bet博彩公司 .
有关MySQL NDB Cluster 7.5更改的概述,请参见NDB 7.5集群有什么新变化.
这个版本还包含了以前NDB集群版本中所有的错误修复和更改,以及从MySQL 5.7到MySQL 5.7.10主线中添加的所有错误修复和功能更改MySQL 5.7.10的变化(2015-12-07,通用版)).
重要的变化:在此之前,
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集群配置文件中使用这些参数中的任何一个现在都会导致错误。有关更多信息,请参见NDB 7.5集群有什么新变化.(Bug #77404, Bug #21280428)
重要的变化:的
ndbinfo
由于以下更改,数据库现在可以提供MySQL NDB集群节点配置参数的默认和当前信息:的
config_params
表中增加了额外的列,提供关于每个配置参数的信息,包括其类型、默认值以及最大值和最小值(如果适用)。一个新的
config_values
表已添加。该表中的一行显示给定节点上参数的当前值。
你可以通过连接这两个表来获得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)NDB复制:通常情况下,
重置的奴隶
中删除所有条目mysql.ndb_apply_status
表格此版本增加了ndb_clear_apply_status
系统变量,这使得重写此行为成为可能。这个变量是在
默认情况下;设置为从
保持重置的奴隶
从净化ndb_apply_status
表格(错误# 12630403)已弃用的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_MEMORY
在MySQL 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
有关连续尝试连接到管理服务器的次数和时间的程序已更改,如下所示:的最小值
——connect-retry-delay
所有人共有的选项NDB
程序由0改为1;这意味着NDB
程序现在在连续的连接尝试之间等待至少1秒,并且不再可能将等待时间设置为0。的语义。
——connect-retries
选项有轻微的改变,这样该选项的值现在设置的次数NDB
程序试图连接到管理服务器。现在将此选项设置为0将导致程序无限期地尝试连接,直到它成功或通过其他方式(例如杀了).此外,默认为
——connect-retries
选项。ndb_mgmClient已从3更改为12,以便在使用时此选项的最小值、最大值和默认值ndb_mgm现在和其他的完全一样吗NDB
项目。的ndb_mgm
——try-reconnect
选项,虽然在MySQL NDB集群7.4中已弃用,但仍然作为同义词被支持ndb_mgm——connect-retries
提供向后兼容性。的默认值——try-reconnect
也分别从3个改为12个,所以这个选项继续以完全相同的方式表现——connect-retries
.
(错误# 22116937)
重要的变化:在以前版本的MySQL NDB集群中,其他DDL操作不能作为
修改在线表…重命名…
.(修复BUG#16021021时不允许此操作。)MySQL NDB Cluster 7.5的改动如下:支持
在线
而且离线
关键字,在MySQL NDB集群7.3中被弃用,现在被移除,使用这些现在会导致语法错误;的NDB
存储引擎现在接受只有算法= default
,算法=复制
,算法= inplace
要指定改变
操作是复制或原地,就像在标准的MySQL服务器。NDB
现在允许修改表…算法=复制重命名
.
(Bug #20804269, Bug #76543, Bug #20479917, Bug #75797)
参考:参见Bug #16021021。
NDB磁盘数据:类的列上的唯一索引
NDB
表使用相关的内部有序索引实现,用于扫描。在删除索引时,首先删除这个有序索引,然后删除惟一索引本身。这意味着,当由于(例如)违反约束而拒绝删除时,语句将被拒绝,但关联的有序索引仍然被删除,因此任何使用扫描该表的后续操作都会失败。我们通过在删除有序索引之前先删除唯一索引来解决这个问题;当删除唯一索引失败时,将不再执行删除相关有序索引。(Bug #78306, Bug #21777589)NDB复制:虽然二进制日志注入器线程处理的是失败事件,但这对所有线程都是可能的
NDB
将表无限期地留在只读模式。这是由于二进制日志注入器线程和处理ndb_schema表上事件的实用程序线程之间存在竞争条件,并且当处理失败事件时,二进制日志注入器线程将所有NDB
表处于只读模式,直到所有这些事件被处理,线程重新启动。当二进制日志注入线程接收到一组一个或多个失败事件时,它将放弃所有其他现有事件操作,并期望实用程序线程不再提供更多事件,直到它处理完所有失败事件,然后重新启动自己。然而,当注入器线程正在处理失败时,实用程序线程可能会继续尝试二进制日志设置,从而尝试在这些表上创建模式分布表以及事件订阅。如果这些表的创建和事件订阅发生在这段时间内,二进制日志注入器线程期望没有进一步的事件操作就永远不会满足;因此,注入器线程永远不会重新启动
NDB
如前所述,表仍然是只读的。为了解决这个问题,
Ndb
对象后,处理模式事件的对象现在肯定会被删除ndb_schema
表删除事件被处理,所以在注入器线程重新启动之前,实用程序线程不能创建任何新的事件,此时,一个新的Ndb
对象用于处理模式事件。(Bug #17674771, Bug #19537961, Bug #22204186, Bug #22361695)NDB集群api:二进制日志注入器无法正常工作
TE_INCONSISTENT
事件类型的处理Ndb: nextEvent ()
.(错误# 22135541)参考:参见Bug #20646496。
NDB集群api:在执行
dropEvent ()
,如果协调器DBDICT
在订阅管理器(SUMA
Block)删除了所有订阅,但在协调器从系统表中删除事件之前,被删除的事件仍然保留在表中,导致后续任何具有相同名称的删除或创建事件都失败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:在集群故障导致的节点初始重新启动之后,当重新启动之前存在的事件稍后被删除时,作为重新启动过程一部分添加的集群故障事件也将被删除。这意味着,在这种情况下,Event API客户端无法知道需要进行故障处理。此外,GCI用于最终清除已删除事件操作,由
pollEvents ()
而且nextEvent ()
当这些方法消耗完所有可用事件时,就丢失了。(Bug #78143, Bug #21660947)MySQL NDB集群7.4.8无意中引入了一个严重的倒退,本地检查点和重新启动的时间通常比预期的要长得多。发生这种情况是因为设置为
MaxDiskWriteSpeedOwnRestart
在重新启动时被忽略,且MaxDiskWriteSpeedOtherNodeRestart
,默认情况下比的默认值要低得多MaxDiskWriteSpeedOwnRestart
改为使用。此问题仅影响重启时间和性能,对正常操作没有影响。(错误# 22582233)集群日志中提供的最新可恢复检查点的历元,作为其报告的一部分
EventBufferStatus
事件(见NDB集群:集群日志中的消息)定义不清楚,因此不可靠;根据不同的因素,报告的epoch可以是当前正在使用的epoch、最近使用的epoch或下一个排队等待使用的epoch。此修复可确保最新的可恢复全局检查点始终被视为用户最近完全使用的检查点,因此它是生成报告时存在的最新的可恢复全局检查点。(错误# 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—We are adjustment Max Disk Write Speed, a restart is ongoing now…2015-06-24 01:08:02 [ndbd] INFO—我们正在调整最大磁盘写速度,不再重新启动
现在只由活动LDM实例执行此日志记录。(错误# 21362380)
备份时错误报告备份块状态。(错误# 21360188)
参考:参见Bug #20204854, Bug #21372136。
在
GET_TABINFOREQ
在执行创建索引
mysqld返回错误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)
重做日志过载时,挂起的操作正在排队(
DefaultOperationRedoProblemAction
API节点配置参数)会导致数据节点重做日志空间(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之间设置,默认值为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_operations
转换顺序
如果有多个并发冲突或死锁的事务,每个事务都有几个挂起的操作,则会导致运行查询的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)
当发送缓冲区成为限制资源时,由于发送缓冲区资源配置不足,通信缓慢或失败导致所有发送缓冲区耗尽,或者慢速接收器未能消耗所发送的内容,可能最终导致发送缓冲区互斥锁。在这种情况下,工作线程无法为信号分配发送缓冲区内存,并试图强制发送以释放空间,而与此同时,发送线程正忙着试图发送到同一个或多个节点。所有这些线程都在竞争使用发送缓冲区互斥锁,这导致了已经描述的锁,由看门狗报告为
发送卡住
.此修复分为两部分,列出在这里:发送线程在获取发送缓冲区互斥量时不再持有全局发送线程互斥量;现在它会在锁定发送缓冲区互斥锁之前释放全局互斥锁。在这种情况下,这可以防止工作线程在发送中卡住。
由发送线程完成的发送缓冲区互斥锁现在使用try-lock。如果尝试锁定失败,将发送到的节点重新插入到发送节点列表的末尾,以便稍后重试。这将删除
发送卡住
发送线程的条件。
(Bug #77081, Bug #21109605)