MySQL NDB Cluster 7.3.10是NDB Cluster的一个新版本,基于MySQL Server 5.6,包含了从版本7.3NDB
存储引擎,并修复了一些最近发现的bug在以前的NDB集群版本。
获取MySQL NDB Cluster 7.3。MySQL NDB Cluster 7.3源代码和二进制文件可以从10bet博彩公司 .
有关MySQL NDB Cluster 7.3中所做更改的概述,请参见新db集群7.3有什么新进展.
该版本还包含了之前NDB集群版本中所做的所有bug修复和更改,以及从MySQL 5.6到MySQL 5.6.25主线中添加的所有bug修复和特性更改MySQL 5.6.25(2015-05-29,通用可用性)).
MySQL NDB ClusterJ:在高工作负载下,可能会使用于返回域对象的直接内存过载,因为直接内存不像在堆上分配对象那样被垃圾收集。ClusterJ实现中添加了两种策略:首先,直接内存现在被池化,这样当域对象被垃圾收集时,直接内存可以被另一个域对象重用。此外,一个新的用户级方法,
发布(实例)
,已添加到会话
接口,该接口允许用户在相应的域对象被垃圾回收之前释放直接内存。参见描述释放(T)更多信息。(错误# 20504741)在处理由于在本地检查点(LCP)期间执行大量插入而导致的过载问题时,这里列出了一些改进:
在尝试执行撤消日志时,由于无法找到日志的结束部分,在重新启动处理过程中有时会发生失败。当写入第二个undo文件时,在第一个undo文件的末尾仍然有未写入的页面时,就会发生这种情况,这将导致以相反的顺序执行undo日志,从而执行旧的甚至不存在的日志记录。
通过确保undo日志的执行从日志的正确末尾开始,并且如果更早地开始,则忽略任何未写的或错误的页面,可以解决这个问题。
在LCP期间,或者在执行
COPY_FRAGREQ
,由于运行记录用完。我们通过确保LCPs和COPY_FRAG
使用为操作记录保留的资源,就像扫描记录一样。此外,删除了ACC操作中不再需要但可能导致失败的旧代码。当在加载表时执行LCP时,在LCP扫描期间可能会命中一个活动锁,因为在LCP启动后插入到新页的每个记录都有它的
LCP_SKIP
标记集。这些记录被LCP扫描丢弃,但是当插入发生的速度比LCP扫描丢弃记录的速度快时,扫描就会挂起。作为这个问题的一部分,扫描没有向LCP看门狗报告任何进展,在livelock启动70秒后,LCP看门狗杀死了进程。当使用单个LDM在较长时间内(120秒或更长时间)每秒插入250000次时,观察到这个问题。这部分修复做了一些更改,如下所示:
我们现在确保在LCP启动后创建的页面不包括在LCP扫描中;我们还确保插入到这些页面的任何记录都没有
LCP_SKIP
标记集。对扫描协议的处理被改变,这样LCP不管负载如何都可以执行一定量的进度;我们现在向LCP看门狗报告进展,以避免在LCP正在进展但没有写入任何记录的情况下出现故障。
我们现在采取措施,确保LCP扫描比插入更快地进行,确保扫描在扫描活动中优先进行,因此,LCP实际上(最终)完成了。
此外,通过预取元组,扫描变得更加高效;这有助于避免在CPU中获取内存时出现停顿。
用于防止数据损坏的行校验和现在包括元组头位。
(Bug #76373, Bug #20727343, Bug #76741, Bug #69994, Bug #20903880, Bug #76742, Bug #20904721, Bug #76883, Bug #20980229)
重要的变化;NDB集群接口:增加了方法
Ndb: isExpectingHigherQueuedEpochs ()
到NDB API,以检测何时检测到额外的、更新的事件周期pollEvents2 ()
.的行为
Ndb: pollEvents ()
也修改过,所以现在返回NDB_FAILURE_GCI(等于~ (Uint64) 0
)当检测到集群故障时。(错误# 18753887)NDB集群接口:添加了
专栏::getSizeInBytesForRecord ()
方法,该方法返回列所需的大小NdbRecord
,取决于列的类型(文本/blob或其他)。(错误# 21067283)NDB集群接口:的创造和毁灭
Ndb_cluster_connection
多个线程的对象可能会使用相同的应用程序锁,这在某些情况下会导致全局字典缓存失败。为了缓解这个问题,已经序列化了几个内部NDB API对象的创建和销毁。(错误# 20636124)NDB集群接口:NDB API中有很多超时没有正确处理。(错误# 20617891)
NDB集群接口:当一个
Ndb
对象被重用,则此对象的事件队列仍可包含发生在故障之前的数据节点事件。这些事件可以参考”老”epoch(从故障发生之前开始),这反过来又可能违反nextEvent ()
方法,使历元数始终增加。在这种情况下,可以通过显式清除事件队列来解决此问题。(错误# 18411034)参考文献:参见Bug #20888668。
MySQL NDB ClusterJ:当与Java 1.7或更高版本一起使用时,在查询带有BLOB列的表时,ClusterJ可能会导致Java VM崩溃,因为
NdbDictionary: createRecord
计算记录所需的错误大小。随后,当ClusterJ调用NdbScanOperation: nextRecordCopyOut
,数据超出分配的缓冲区空间。通过这个修正,ClusterJ检查由NdbDictionary: createRecord
并使用该值作为缓冲区大小,如果它大于ClusterJ自己计算的值。(错误# 20695155)在运行恢复数据库元数据(而不是任何数据)之后ndb_restore
——restore-meta
(或- m
)时,SQL节点将挂起选择
从数据库中元数据恢复到的表。在这种情况下,查询表的尝试会如预期的那样失败,因为表直到ndb_restore使用——恢复数据
(- r
).(错误# 21184102)参考文献:参见Bug #16890703。
当大量线程在NDB API中连续快速地打开和关闭块时,内部
close_clnt ()
同步关闭块的函数等待的时间不够长,以至于一个自信号表明需要处理潜在的附加信号。这导致过多的CPU使用ndb_mgmd,并阻止其他线程打开或关闭其他块。通过将函数轮询调用更改为等待唤醒的特定条件(也就是说,在实际执行信号时),可以解决这个问题。(错误# 21141495)以前,可以调用多个发送线程来处理发送到同一个节点的消息;这些线程然后竞争相同的发送锁。当发送锁阻塞额外的发送线程时,工作线程可以被传递到其他节点。
这个问题可以通过确保在已经有活动的发送线程分配给同一节点时没有激活新的发送线程来解决。此外,已经分配了一个活动的发送线程的节点对其他已经活动的发送线程不再可见;也就是说,当发送线程当前分配给该节点时,该节点将不再被添加到节点列表中。(Bug #20954804, Bug #76821)
当重做日志过载时,挂起的操作正在排队(
DefaultOperationRedoProblemAction
API节点配置参数)可能导致超时,当数据节点耗尽重做日志空间(P_TAIL_PROBLEM错误)。现在,当重做日志已满时,节点将中止请求,而不是将其排队。(错误# 20782580)参考文献:参见Bug #20481140。
NDB
的错误延迟可以延迟统计信息查询ndb_index_stat_option
(默认60秒)当查询的索引被标记为内部错误。同样的潜在问题也可能引起分析表
绞死:在对…执行绞刑时被绞死NDB
表具有多个索引,其中一个或多个索引上发生了内部错误,但不是所有索引上都发生了内部错误。现在,在这种情况下,将立即返回任何现有的统计信息,而不等待发现任何额外的统计信息。(Bug #20553313, Bug #20707694, Bug #76325)
多线程调度器可以直接从每个工作线程发送到远程节点,也可以从专用的发送线程sl发送到远程节点,具体取决于集群的配置。此发送可能传输来自发送缓冲区的所有、部分或全部可用数据。当发送数据仍然挂起时,工作线程或发送线程继续尝试在一个循环中发送。在最近一次尝试执行发送时发送的数据的实际大小现在被跟踪,并被发送线程或工作线程用于检测发送进度的不足。当没有任何进展,也没有其他未完成的工作时,调度器将暂停1毫秒来释放CPU供其他线程使用。(错误# 18390321)
参考文献:参见Bug #20929176, Bug #20954804。
在某些情况下,试图恢复以前备份过的表时,使用文件未找到由于缺少表片段文件而发生错误。这是NDB内核的结果
备份
阻塞接收忙试图获取表描述时出错,原因是来自外部客户端的其他流量,没有重新尝试操作。此问题的修复为此类请求创建两个单独的队列—一个用于内部客户机,例如
备份
块或ndb_restore一个用于API节点等外部客户机,并对内部队列进行优先级排序。注意,使用NDB API的外部客户端应用程序(包括针对SQL节点运行的MySQL应用程序)总是需要处理的忙在以后重试事务时出错;这个期望是不此问题的修复更改了。(错误# 17878183)
参考文献:参见Bug #17916243。
在某些情况下
DBDICT
块处理重复失败GET_TABINFOREQ
第一个后的信号,导致可能的节点故障和重启。设置足够高的值后可以观察到这一点MaxNoOfExecutionThreads
低价值LcpScanProgressTimeout
.(Bug #77433, Bug #21297221)客户端查找,以便API信号通过内部传递到正确的客户端
TransporterFacade: deliver_signal ()
函数没有互斥锁保护,这可能导致测试期间遇到的超时等问题,当其他客户机连接到同一函数时TransporterFacade
.(Bug #77225, Bug #21185585)当发送缓冲区成为限制资源时,可能会导致发送缓冲区互斥锁的结果,这可能是由于发送缓冲区资源配置不足、通信缓慢或失败(导致所有发送缓冲区耗尽)的问题,或者速度较慢的接收方未能消耗所发送的内容。在这种情况下,工作线程无法为信号分配发送缓冲区内存,并试图强制发送以释放空间,而与此同时,发送线程正忙于试图发送到同一个或多个节点。所有这些线程都在竞争获取发送缓冲区互斥锁,这导致了已经描述过的锁,由看门狗报告为
卡在发送
.此修复分为以下两部分:发送线程在获取发送缓冲区互斥锁时不再持有全局发送线程互斥锁;它现在会在锁定发送缓冲区互斥锁之前释放全局互斥锁。这可以防止工作线程在这种情况下被卡住。
由发送线程完成的发送缓冲区互斥锁现在使用尝试锁。如果尝试锁定失败,将发送到的节点重新插入到发送节点列表的末尾,以便稍后重试。这将删除
卡在发送
发送线程的条件。
(Bug #77081, Bug #21109605)