MySQL NDB集群7.6.13是基于MySQL Server 5.7的NDB 7.6的新版本,包括版本7.6中的功能NDB
存储引擎,以及修复最近发现的bug在以前的NDB集群版本。
获取NDB集群7.6。NDB Cluster 7.6的源代码和二进制文件可以从10bet博彩公司 。
关于NDB Cluster 7.6中更改的概述,请参见什么是NDB集群7.6。
此版本还包含所有错误修复和在先前的NDB群集版本中进行的更改,以及在MySQL 5.7中的MySQL 5.7中添加的所有错误修复和功能更改(参见MySQL 5.7.29 (2020-01-13, General Availability))。
重要变化:现在可以将备份划分为切片并使用为此实现的两个新选项并行恢复这些ndb_restore效用,使得可以使用多个实例ndb_restore并行恢复与备份大小大致相同的子集,这应该有助于减少从备份恢复NDB Cluster所需的时间长度。
这
- 纳米切片
选项确定备份应分割的切片数;——slice-id
提供待恢复的片ID(小于片数0 ~ 1)ndb_restore。最多支持1024个切片。
有关更多信息,请参阅以下说明
- 纳米切片
和——slice-id
选项。(bug#30383937)
不兼容的更改:最小值
redoovercommitcounter
数据节点配置参数从0增加到1.最小值RedoOverCommitLimit
数据节点配置参数也从0增加到1。您应该检查集群全局配置文件,并在升级之前对为这些参数设置的值进行必要的调整。(错误# 29752703)
微软的Windows操作系统;NDB磁盘数据:在Windows上,当使用磁盘数据表时,重新启动主节点以外的数据节点导致在
特克曼
。(bug#97436,bug#30484272)NDB磁盘数据:在NDB 7.6中引入版本2格式之前使用的版本1磁盘格式的兼容性代码被证明是不必要的,并且不再使用。
一个错误的
ndbrequire()
在实现部分本地检查点时引入的假设m_participatinglqh.
接收时一定要清楚吗START_LCP_REQ
,当主机在发送后发生故障时,这并不一定是真的START_LCP_REQ
在处理之前START_LCP_CONF
信号。(bug#30523457)当主节点在发送
lcp_complete_rep.
信号和它被发送到某些节点,但不是所有的节点。(bug#30520818)执行ndb_restore
——rebuild-indexes
和我们一起——rewrite-database
和——exclude-missing-tables
选项没有为目标数据库中的任何表创建索引。(bug#30411122)当同步范围页面时,当前本地检查点(LCP)可能是无限期的,如果a
继续
信号处理LCP仍未收到FSWRITECONF
区段同步页中最后一页的信号。如果从数据页写入另一个页,也可以重新启动LCP。也有可能是这个问题引起的prep_lcp.
在他们不应该是的时候要写的页面。(bug#30397083)如果事务在从磁盘页缓冲区获取页时中止,并且磁盘系统过载,则事务将无限期挂起。这也可能导致重启挂起和节点故障处理失败。(Bug #30397083, Bug #30360681)
参考:参见Bug #30152258。
数据节点故障导致错误系统重启期间,另一个节点失效……在部分重启期间发生。(错误# 30368622)
如果一个
SYNC_EXTENT_PAGES_REQ
接收到的信号PGMAN
将日志文件组丢弃作为部分本地检查点的一部分,从而丢弃由此块锁定的页面进行处理接下来,LCP由于尝试在已丢弃之后访问该页面而终止。(bug#30305315)已完成的本地检查点的集群日志中报告了错误的字节数。(错误# 30274618)
参考:参见Bug #29942998。
当备份完成的群集日志中写入群集日志中的摘要事件的数据字节数被截断为32位,以便在日志记录数和日志中打印的数据记录数之间存在显着不匹配。(bug#29942998)
在2节点群集中使用2个LDM线程,每个节点10个线程可能导致分区不平衡,使得每个节点上的LDM线程之一是零片段的主机。尝试从此群集恢复多线程备份失败,因为一个LDM的数据文件仅包含12字节数据文件头,这ndb_restore无法读。在其他情况下可能发生同样的问题,例如在在线添加空节点后立即拍摄备份时。
人们发现这种情况发生在
odirect.
日志含义对小于512字节的EOF备份数据文件进行写操作,备份数据在stop
状态。这通常仅发生在中止备份,但也可能发生成功备份,其中LDM没有碎片。我们通过引入额外检查来解决此问题,以确保仅在备份实际包含一个错误时才会跳过写入,这应该导致它中止。(bug#29892660)参考文献:另见:Bug#30371389。
在某些情况下
SignalSender
类,作为实施的一部分ndb_mgmd和ndbinfo
,缓冲了过多不必要的数据SUB_GCP_COMPLETE_REP
和api_regconf.
信号,导致不必要的内存消耗。(bug#29520353)参考:参见:Bug #20075747, Bug #29474136。
设置为
backuprogbuffersize.
配置参数未被尊重。(错误# 29415012)每当节点关闭时,重新计算最大全局检查点(GCP)提交LAG和GCP保存超时,以考虑数据节点数量的更改。当阈值下降到之前的值下降时,这可能导致无意关闭的可行节点。(bug#27664092)
参考文献:另见:Bug#26364729。
插入子行的事务可以与事务同时运行,该事务删除该子项的父行。在这种情况下,应该中止其中一个事务,以免孤儿儿童行结果。
在提交子行上的INSERT之前,触发读取父行以确认父级是否存在。类似地,在提交父行上的删除之前,执行读取或扫描以确认不存在子行。当同时插入和删除事务运行时,他们的准备和提交操作可以以这样的方式进行交互,即两个事务所提出的。这发生了因为触发的读取是使用的
lm_commitedread.
锁(参见ndboperation :: lockMode.
),这不足以防止此类错误方案。这个问题可以通过使用更强的来解决
LM_SimpleRead
两个触发读取的锁定模式。指某东西的用途LM_SimpleRead
而不是lm_commitedread.
锁确保在涉及并发地插入子行和从父行删除的事务的每个可能场景中至少有一个事务中止。(错误# 22180583)并发
选择
和改变表
在等待释放锁时,同一个SQL节点上的语句有时会相互阻塞。(Bug #17812505, Bug #30383887)