MySQL NDB集群7.3.5是一个新的NDB集群版本,它基于MySQL Server 5.6,包含了MySQL Server 7.3的一些特性NDB
存储引擎,以及修复了以前NDB集群版本中最近发现的一些错误。
获取MySQL NDB集群7.3。MySQL NDB集群7.3源代码和二进制文件可以从10bet博彩公司 .
有关MySQL NDB Cluster 7.3中所做更改的概述,请参见NDB集群7.3有什么新功能.
此版本还包含了以前NDB集群版本中所有的错误修复和更改,以及从MySQL 5.6到MySQL 5.6.17主线中添加的所有错误修复和功能更改(参见MySQL 5.6.17(2014-03-27,一般可用性)).
的处理
LongMessageBuffer
不足和统计数据改进如下:的默认值
LongMessageBuffer
已从4 MB增加到64 MB。当此资源耗尽时,将在数据节点日志中打印适当的信息消息,描述问题的可能原因并建议可能的解决方案。
LongMessageBuffer
使用信息现在显示在ndbinfo.memoryusage
表格有关示例和其他信息,请参见该表的描述。
重要的变化:服务器系统变量
ndb_index_cache_entries
而且ndb_index_stat_freq
,在以前的MySQL NDB集群发布系列中已经被弃用,现在已经被移除。(Bug #11746486, Bug #26673)复制:日志旋转事件可能导致
group_relay_log_pos
在一个组中不正确地向前移动。这意味着,当重试事务时,或者在一个或多个日志旋转(例如事务或组跨越多个中继日志文件)之后在事务中间停止SQL线程时,将无声地跳过组的部分或全部。此问题已通过纠正逻辑中的一个问题得到解决,该逻辑用于避免在作为中继日志旋转的一部分更新日志位置时触及SQL线程的坐标,因此可以在不使用多线程从机时更新SQL线程的坐标,甚至在组的中间。(错误# 18482854)
Solaris:在为Solaris平台编译MySQL NDB集群软件时发现的问题可能导致在使用时出现问题
ThreadConfig
在这样的系统上。(错误# 18181656)NDB复制:MySQL NDB集群复制中的从服务器现在监视从上游主机接收到的纪元号的进程,这既可以作为对复制低级功能的有用检查,也可以在复制意外地在已经应用的位置重新启动时提供警告。
作为这种增强的结果,epoch ID冲突会产生以下结果,这取决于从SQL线程的状态:
(错误# 17461576)
参考:参见Bug #17369118。
NDB集群api:当NDB API客户端应用程序接收到带有无效块或信号号的信号时,
NDB
只提供了一个非常简短的错误消息,没有准确地传达问题的性质。现在,在这种情况下,当检测到错误信号或消息时,将提供适当的打印输出。此外,现在还检查消息长度,以确保它与嵌入信号的大小匹配。(错误# 18426180)NDB集群api:在MySQL NDB集群7.3.4中执行的重构无意中引入了一个依赖项
Ndb.hpp
在未包含在发行版中的文件上,这导致NDB API应用程序无法编译。依赖项已被移除。(Bug #18293112, Bug #71803)参考:这个问题是Bug #17647637的回归。
NDB集群api:一个NDB API应用程序发送一个扫描查询到一个数据节点;扫描由事务协调器(TC)处理。TC转发
LQHKEYREQ
请求发送给适当的LDM,如果没有接收到LQHKEYCONF
在规定的时间内响应。事务中止成功后,TC发送一个TCROLLBACKREP
发送到NDBAPI客户端,NDBAPI客户端通过清除任何Ndb
与事务关联的对象。客户端以的形式接收它所请求的数据
TRANSID_AI
为在数据节点发送而经过缓冲的信号,可以在延迟后传递。一收到这样的信号,NDB
检查事务状态和ID:如果这些是预期的,它使用Ndb
与该事务关联的对象。当满足以下所有条件时,就会出现当前错误:
事务协调器由于延迟而中止事务,并发送
TCROLLBACPREP
信号传递给客户端,同时TRANSID_AI
为在LDM上交付而缓冲的文件被交付到同一个客户机。NDB API客户端在收到
TCROLLBACKREP
信号,并立即关闭事务。客户端有一个单独的接收线程与正在关闭事务的线程并发运行。
姗姗来迟
TRANSID_AI
与用户线程的事务的关闭交叉TRANSID_AI
处理前通过正常检查closeTransaction ()
重置事务状态并使接收方失效。
当这些条件都满足时,接收线程将继续处理
TRANSID_AI
使用无效接收器的信号。由于接收器已经失效,它的使用将导致节点故障。现在,
Ndb
已执行的对象清理TCROLLBACKREP
包括事务ID的无效,因此,对于给定的事务,在TCROLLBACKREP
到达时没有通过事务ID检查,并被静默删除。也实现了此修复TC_COMMITREF
,TCROLLBACKREF
,TCKEY_FAILCONF
,TCKEY_FAILREF
还有信号。另请参阅操作和信号,以获取有关NDB消息传递的更多信息。(错误# 18196562)
NDB集群api:这个例子
ndbapi-examples / ndbapi_blob_ndbrecord / main.cpp
包括一个内部头文件(ndb_global.h
)在MySQL NDB集群二进制分布中找不到。下面的示例使用stdlib.h
而且string.h
而不是这个文件。(Bug #18096866, Bug #71409)NDB集群api:当
字典:dropTable ()
试图(作为其内部操作的正常部分)删除外键约束使用的索引,删除失败。在这种情况下,调用dropTable ()
使表上的所有外键都被删除,无论此表作为父表、子表或同时作为父表。此问题不影响使用SQL语句删除索引。(错误# 18069680)
参考:参见Bug #17591531。
NDB集群api:ndb_restore有时会报告错误701系统忙于其他模式操作在并行恢复时不必要。(错误# 17916243)
当一个
ALTER TABLE
语句改变了表模式,但没有改变表的分区,新的表定义没有从旧定义复制哈希映射,而是使用当前的默认哈希映射。但是,表数据没有根据新的哈希映射进行重组,这使得如果两个哈希映射具有不兼容的定义,那么使用主键查找就无法访问某些行。为了防止这种情况发生,任何
ALTER TABLE
这需要一个hashmap更改,现在触发表的重组。此外,在这种情况下复制表定义时,也会复制散列映射。(错误# 18436558)当某些查询在节点故障之前生成了超过18个数据字的信号时,跟踪文件中就不会正确地写入这些信号。(错误# 18419554)
超时检查由信号处理
TIME_SIGNAL
.以前,这个信号是由QMGR
NDB
内核块在主线程中,并发送到QMRG
,DBLQH
,DBTC
块(见NDB内核块)根据需要(分别)检查心跳、磁盘写入和事务超时。在ndbmtd(而不是ndbd),这些块都在不同的线程中执行。这意味着,例如,QMGR正在积极工作和一些其他线程被置于睡眠,先前睡眠线程收到大量TIME_SIGNAL当它再次被唤醒时,信息同时出现,有效时间很快就过去了DBLQH以及在DBTC.在DBLQH在美国,这没有明显的不良影响,但在美国,情况并非如此DBTC;后一个块不能在事务上工作,即使时间仍然在前进,导致许多操作似乎超时的情况,因为事务协调器(TC)线程在响应请求时相对较慢。此外,当TC线程的睡眠时间超过1500毫秒时,由于检测到超时处理循环尚未停止,数据节点崩溃。为了纠正这一问题,产生了
TIME_SIGNAL
已经移动到本地线程而不是QMGR
;这可以更好地控制速度TIME_SIGNAL
允许消息到达。(错误# 18417623)的
ServerPort
而且TcpBind_INADDR_ANY
的输出中不包括配置参数ndb_mgmd——print-full-config
.(错误# 18366909)摔了一跤之后
NDB
表中,既没有集群日志也没有输出报告MemoryUsage
命令显示IndexMemory
该表使用的所有内存都被释放了,尽管该内存实际上已被释放。此问题在MySQL NDB Cluster 7.3.2中引入。(错误# 18296810)ndb_show_tables有时出现错误消息失败无法连接到管理服务器并立即终止,没有提供失败的根本原因。类中的最新错误现在也打印出来,以便在这种情况下提供更多有用的信息
Ndb_cluster_connection
用于实例化连接的对象。(错误# 18276327)-DWITH_NDBMTD = 0
在ARM和树莓派等没有定义编译所需内存屏障函数的平台上,这可能会导致编译失败ndbmtd.(错误# 18267919)参考:参见Bug #16620938。
由多线程调度程序管理的块线程通过在所有块线程之间建立的输出队列或作业缓冲区中放置信号进行通信。这个队列有一个固定的最大大小,因此当它被填满时,工作线程必须等待使用者耗尽队列。在高负载的系统中,由于缓冲区已满,多个线程可能会在循环等待锁中结束,这样它们就会阻止彼此执行任何有用的工作。这种情况最终导致数据节点被看门狗计时器宣布死亡并杀死。
为了解决这个问题,我们检测循环等待锁即将开始的情况,并使原本处于预留状态的缓冲区可用于高负载队列的信号处理。(错误# 18229003)
的ndb_mgm客户端
开始备份
命令(见NDB集群管理客户端的命令)可能会经历偶尔的随机失败,当一个ping在预期之前收到BackupCompleted
事件。现在,在正确地建立连接之前,不会检查此命令建立的连接。(错误# 18165088)当创建一个外键引用另一个表中的索引的表时,有时即使索引中的列的顺序不匹配,也可以创建外键,这是因为并不总是在内部返回适当的错误。此修复改进了在大多数情况下内部使用的错误;但是,如果父索引是唯一的索引,则仍然可能出现这种情况。(错误# 18094360)
更新外键的父表使用了过多的扫描资源,因此需要异常高的设置
MaxNoOfLocalScans
而且MaxNoOfConcurrentScans
.(错误# 18082045)对象上删除不存在的外键
NDB
表(使用,例如,ALTER TABLE
)似乎成功了。现在,在这种情况下,语句会失败,并出现预期的相关错误消息。(错误# 17232212)数据节点运行ndbmtd在将包含大量表的MySQL NDB集群从NDB 7.2.5之前的版本升级到7.2.5或更高版本时,可能会暂停。(错误# 16693068)