NDB集群api:添加的目的是帮助调试为给定对象指定人类可读的名称的能力
Ndb
对象,然后检索它。这些操作分别实现为setNdbObjectName ()
而且getNdbObjectName ()
方法。跟踪用户应用程序和
NDB
更简单的是,您可以使用引用(fromgetReference ()
在打印输出时,后跟名称(如果提供);引用将应用程序连接在一起Ndb
对象、事件缓冲区和NDB
存储引擎的SUMA
块。(错误# 18419907)
NDB磁盘数据:设置使用的undo缓冲区大小
InitialLogFileGroup
设置的值大于SharedGlobalMemory
阻止数据节点启动;数据节点失败,错误为1504日志缓冲区内存不足.虽然故障本身是预期的行为,但错误消息并没有提供足够的信息来诊断问题的实际来源;在这种情况下,更具体的错误信息日志缓冲区内存不足(指定更小的undo_buffer_size或增加SharedGlobalMemory)供应。(Bug #11762867, Bug #55515)NDB集群api:当两个表具有相同名称的不同外键时,ndb_restore认为这是名称冲突,未能恢复模式。由于此修复,斜杠字符(
/
)现在明确禁止在外键名称和命名格式中使用parent_id
/child_id
/fk_name
现在由NDB API强制执行。(错误# 18824753)NDB集群api:当一个
NDB
数据节点通过空历表示缓冲区溢出,事件缓冲区将不一致的数据事件放入事件队列中。当它被使用时,它没有像预期的那样从事件队列中删除,从而导致后续事件nextEvent ()
调用返回0。这导致事件消耗停止,因为不一致一直保持标记状态,而事件数据在队列中积累。属于空不一致epoch的事件数据可以在开始或中间的某个位置找到。
pollEvents ()
对于第一个情况返回0。此修复程序处理第二种情况:调用nextEvent ()
调用在不一致的事件返回之前将其取消队列。为了从这个修复中受益,用户应用程序必须调用nextEvent ()
即使pollEvents ()
返回0。(错误# 18716991)NDB集群api:的
pollEvents ()
方法返回1,即使在调用时等待时间为0且队列中没有等待事件时也是如此。现在,在这种情况下,它像预期的那样返回0。(错误# 18703871)处理包含无效节点ID的NODE_FAILREP信号可能导致数据节点失败。(Bug #18993037, Bug #73015)
这个问题是Bug #16007980的回归。
在从源代码构建时,一些文件被写入源目录而不是构建目录。这些包括
manifest . mf
文件用于创建ClusterJ jar和pom.xml
所使用的文件mvn_install_ndbjtie.sh
.此外,ndbinfo.sql
写入到构建目录,但标记为输出到?中的源目录CMakeLists.txt
.(Bug #18889568, Bug #72843)当二进制日志注入器线程向二进制日志提交一个epoch时,这会导致日志文件达到最大大小,它可能需要旋转二进制日志。直到所有客户端线程提交的所有事务都刷新到二进制日志中,或者超过30秒,才执行旋转。在所有事务都在30秒等待之前提交的情况下,多个客户端线程提交的事务可能属于较新的epoch,而不是注入器线程提交的最新epoch,导致线程自身死锁,并在打破死锁之前造成不必要的30秒延迟。(错误# 18845822)
如果父索引是父表的主键,主键不在表的初始属性上,且子表不为空,则添加外键失败,NDB Error 208。(错误# 18825966)
当一个
NDB
Table既用作父表,也用作两个具有相同名称的不同外键的子表,删除子表上的外键可能导致父表上的外键被删除,从而导致无法删除剩余的外键的情况。这种情况可以使用以下方法建模创建表
声明:CREATE TABLE parent (id INT NOT NULL, PRIMARY KEY (id)) =NDB;CREATE TABLE child (id INT NOT NULL, parent_id INT, PRIMARY KEY (id), INDEX par_ind (parent_id), FOREIGN KEY (parent_id)引用parent(id))CREATE TABLE孙子(id INT, parent_id INT, INDEX par_ind (parent_id), FOREIGN KEY (parent_id)引用子(id) ENGINE=NDB;
对于刚才所示创建的表,问题在执行语句时发生
删除表子表外键parent_id
,因为在某些情况下这是可能的NDB
来删除外键孙子
表。方法中删除外键的任何后续尝试孩子
或从孙子
表失败。(错误# 18662582)数据节点的重新启动有可能无限期地卡在启动阶段101(参见NDB集群启动阶段总结)当重新启动的节点与一个或多个订阅API节点之间存在连接问题时。
为了帮助防止这种情况发生,可以使用一个新的数据节点配置参数
RestartSubscriberConnectTimeout
,它可用于控制数据节点重启在启动阶段101中暂停的时间,然后再放弃并尝试再次重启。默认值是12000 ms. (Bug #18599198)执行
ALTER TABLE……重组分区
将集群中的数据节点数量从4个增加到16个后,导致数据节点崩溃。这个问题被证明是由之前的修复程序所导致的回归,该修复程序使用已经在使用的转储代码(7019)添加了一个新的转储处理程序,这导致该命令执行两个具有不同语义的不同处理程序。新联络员被分配了一个新的转储
代码(7024)。(错误# 18550318)这个问题是Bug #14220269的回归。
当运行一个相对较小的重做日志和一个不足的大值
MaxNoOfConcurrentTransactions
,仍然有事务因为缺少重做日志而被阻塞,因此没有在正确的状态下中止(等待准备日志发送到磁盘,或LOG_QUEUED
状态)。这导致重做日志一直处于阻塞状态,直到本地检查点完成解除阻塞。这可能导致死锁,因为阻塞的中止转而阻塞全局检查点,阻塞的GCPs阻塞lcp。为了防止这种情况发生,我们一到达LOG_QUEUED
中止状态处理程序中的状态。(错误# 18533982)ndbmtd支持多个并行的接收线程,每个线程通过在节点启动时确定的remote_nodes到接收线程的映射,为远程节点连接(传输器)的一个子集执行信号接收。连接控制由多实例管理
TRPMAN
块,它被组织为代理和工作者,每个接收线程有一个TRPMAN
工人在本地运行。的
QMGR
块发送信号到TRPMAN
启用和禁用与远程节点的通信。这些信号被发送到TRPMAN
代理,将它们转发给工人。工作人员自己根据他们管理的远程节点集决定是否对信号采取行动。当前问题的出现是因为
TRPMAN
用于确定它们负责哪个连接的工作人员以这样一种方式实现,即每个工作人员都认为它负责所有连接。这导致了TRPMAN
操作OPEN_COMORD
,ENABLE_COMREQ
,CLOSE_COMREQ
被处理多次。解决一直
TRPMAN
实例(接收线程)正在执行OPEN_COMORD
,ENABLE_COMREQ
而且CLOSE_COMREQ
请求。另外,正确TRPMAN
当从此实例为特定远程连接路由时,现在选择实例。(错误# 18518037)在数据节点故障处理过程中,执行接管的事务协调器收集任何失败的TC实例事务的所有已知状态信息,确定每个事务是已提交还是已中止,并通知任何涉及的API节点,以便它们能够准确地向客户机报告这一点。TC实例通过发送来提供该信息
TCKEY_FAILREF
或TCKEY_FAILCONF
在每个受影响的事务顶部适当地向API节点发送信号。如果这个TC实例与API节点没有直接连接,它会尝试通过与故障TC相同节点组中的另一个数据节点发送信号,并发送一个
GSN_TCKEY_FAILREFCONF_R
向该数据节点中的TC块实例0发送信号。在使用多个事务协调器的情况下,当此TC实例没有针对此类信号的信号处理程序时,就会出现问题,从而导致失败。这个问题通过向TC代理块添加处理程序得到了纠正,在这种情况下,该处理程序将信号转发到一个本地TC工作者实例,该实例又尝试将信号转发到API节点。(错误# 18455971)
当在不同的cpu上使用非常慢的主线程和一个或多个事务协调器线程运行时,在发送一个
DIH_SCAN_GET_NODESREQ
信号,这可能导致数据节点崩溃。在这种情况下,可以避免超时。(错误# 18449222)使用时多个节点故障ndbmtd在中等流量的情况下,不能很好地处理多个TC线程,这在某些情况下可能导致集群意外关闭。(错误# 18069334)
使用全局LCP状态跟踪本地检查点(LCP) (
c_lcpState
),并且每个NDB
表有一个状态指示器,指示该表的LCP状态(tabLcpStatus
).如果全局LCP状态为LCP_STATUS_IDLE
,那么所有表的LCP状态应该为TLS_COMPLETED
.当LCP启动时,全局LCP状态为
LCP_INIT_TABLES
线程开始设置所有的NDB
表TLS_ACTIVE
.如果任何表还没有为LCP准备好,LCP初始化过程将继续进行CONTINUEB
发出信号,直到所有表都可用并被标记TLS_ACTIVE
.初始化完成后,全局LCP状态设置为LCP_STATUS_ACTIVE
.当满足以下条件时发生此错误:
一个LCP在
LCP_INIT_TABLES
一些但不是所有的桌子都被摆上了餐桌TLS_ACTIVE
.日志含义全局LCP状态变为前,主节点失败
LCP_STATUS_ACTIVE
;也就是说,在LCP完成所有表的处理之前。的
NODE_FAILREP
最后对节点故障产生的信号进行处理CONTINUEB
信号从LCP初始化过程,以便处理节点故障,而LCP仍在LCP_INIT_TABLES
状态。
主节点发生故障并选择新节点后,新主节点将使用
MASTER_LCPREQ
信号来确定LCP的状态。此时,由于LCP状态为LCP_INIT_TABLES
日志含义当LCP状态重置为LCP_STATUS_IDLE
.但是,表的LCP状态没有被修改,所以仍然有表TLS_ACTIVE
.然后,将故障节点从LCP中删除。如果给定表的LCP状态为TLS_ACTIVE
,则检查全局LCP状态为notLCP_STATUS_IDLE
;此检查失败,导致数据节点失败。现在,
MASTER_LCPREQ
处理程序确保tabLcpStatus
为所有表更新为TLS_COMPLETED
当全局LCP状态变为LCP_STATUS_IDLE
.(错误# 18044717)执行复制时
ALTER TABLE
操作,mysqld创建要修改的表的新副本。这个中间表的名称带有前缀# sql -
,有更新的模式,但不包含数据。mysqld然后将数据从原始表复制到这个中间表,删除原始表,最后用原始表的名称重命名中间表。mysqld将这样的表视为临时表,并且不将其包含在
显示表
;, mysqldump还会忽略中间表。然而,NDB
在这样的中间表和任何其他表之间没有区别。查看中间表的方式的差异mysqld(和MySQL客户端程序)和NDB
如果在执行备份和恢复时存在中间表,则存储引擎可能会产生问题NDB
,可能是失败后留下的ALTER TABLE
使用复制。如果使用执行模式备份, mysqldump和mysql客户端,此表不包括在内。但是,在使用ndb_mgm客户的备份
命令中,中间表被包含,并且被包含ndb_restore,然后由于试图将数据加载到备份模式中没有定义的表中而失败。为了防止此类故障的发生,ndb_restore现在默认忽略期间创建的中间表
ALTER TABLE
操作(即名称以前缀开头的表)# sql -
).有一个新选项——exclude-intermediate-sql-tables
,它可以覆盖新行为。该选项的默认值为真正的
;导致ndb_restore要恢复到旧的行为并试图恢复中间表,请将此选项设置为假
.(错误# 17882305)插入失败的日志记录得到了改进。这是为了帮助诊断写入时偶尔出现的问题
mysql.ndb_binlog_index
表格(错误# 17461625)的
定义者
列INFORMATION_SCHEMA。的观点
控件中包含的视图的错误值ndbinfo
信息数据库。这可以在以下查询的结果中看到从information_schema中选择table_name,定义器。观点,TABLE_SCHEMA = ' ndbinfo '
.(错误# 17018500)雇佣一个
字符
列中使用use UTF8
字符集作为表的主键列导致重新启动数据节点时节点失败。试图恢复具有这样一个主键的表也会导致ndb_restore失败。(Bug #16895311, Bug #68893)的
——订单
(- o
)选项ndb_select_all实用程序仅在指定为最后一个选项时才有效,不能使用等号。作为修复的一部分,这个程序
——帮助
的输出也与——订单
选择正确的行为。(Bug #64426, Bug #16374870)