10bet网址
MySQL NDB集群7.3版本说明
下载这些版本说明
PDF (Ltr)- 0.9 mb
PDF (A4)- 0.9 mb


MySQL NDB集群7.3版本说明/版本系列更新日志:MySQL NDB Cluster 7.3/ MySQL NDB集群7.3.6 (5.6.19-ndb-7.3.6)(2014-07-11,通用可用性)

MySQL NDB集群7.3.6 (5.6.19-ndb-7.3.6)(2014-07-11,通用可用性)

增加或更改的功能

  • 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)

  • 当一个NDBTable既用作父表,也用作两个具有相同名称的不同外键的子表,删除子表上的外键可能导致父表上的外键被删除,从而导致无法删除剩余的外键的情况。这种情况可以使用以下方法建模创建表声明:

    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_COMORDENABLE_COMREQ,CLOSE_COMREQ被处理多次。

    解决一直TRPMAN实例(接收线程)正在执行OPEN_COMORDENABLE_COMREQ而且CLOSE_COMREQ请求。另外,正确TRPMAN当从此实例为特定远程连接路由时,现在选择实例。(错误# 18518037)

  • 在数据节点故障处理过程中,执行接管的事务协调器收集任何失败的TC实例事务的所有已知状态信息,确定每个事务是已提交还是已中止,并通知任何涉及的API节点,以便它们能够准确地向客户机报告这一点。TC实例通过发送来提供该信息TCKEY_FAILREFTCKEY_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线程开始设置所有的NDBTLS_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使用复制。如果使用执行模式备份, mysqldumpmysql客户端,此表不包括在内。但是,在使用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)