MySQL NDB Cluster 7.3.12是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.28主线中添加的所有bug修复和特性更改MySQL 5.6.28(2015-12-07,通用可用性)).
重要的变化:MySQL NDB集群7.3.11和MySQL NDB集群7.4.8中的修复ndb_restore执行唯一键检查,即使在不恢复数据的模式下操作,如使用程序的
——restore-epoch
或——打印数据的
选择。行为的改变导致现有有效的备份例程失败;为了避免此问题影响此版本和以后的版本,已经恢复了以前的修复。这意味着在运行ndb_restore的那些版本中添加的需求
——disable-indexes
或——rebuild-indexes
在包含唯一索引的表上使用时,也会被提升。(错误# 22345748)参考文献:参见Bug #22329365。恢复补丁:Bug #57782, Bug #11764893。
重要提示:如果一个
NDB
有外键的表在其中一个数据节点停止时被删除,该数据节点稍后尝试重新启动时失败。(错误# 18554390)NDB复制:虽然二进制日志注入器线程正在处理失败事件,但这对所有人来说都是可能的
NDB
表将无限保留为只读模式。这是由于二进制日志注入器线程和ndb_schema表上处理事件的实用线程之间存在竞争条件,以及当处理失败事件时,二进制日志注入器线程将所有NDB
表在只读模式下,直到所有这些事件被处理并线程重新启动自己。当二进制日志注入线程接收到一组一个或多个失败事件时,它将放弃所有其他现有事件操作,并期望实用程序线程不再提供更多事件,直到它处理完所有失败事件并重新启动自己。然而,当注入器线程正在处理失败时,实用程序线程可能继续尝试二进制日志设置,从而尝试创建模式分布表以及在这些表上的事件订阅。如果在这段时间内创建了这些表和订阅了事件,那么二进制日志注入器线程期望没有进一步的事件操作的期望就永远不会得到满足;因此,注入器线程永远不会重新启动,并且
NDB
如前所述,表保持只读状态。为了解决这个问题,
Ndb
处理模式事件的对象现在肯定会被删除ndb_schema
表删除事件被处理,因此实用程序线程不能创建任何新的事件,直到注入器线程重新启动,这时,一个新的Ndb
对象,用于处理模式事件。(Bug #17674771, Bug #19537961, Bug #22204186, Bug #22361695)NDB集群api:二进制日志注入器没有正确工作
TE_INCONSISTENT
的事件类型处理Ndb: nextEvent ()
.(错误# 22135541)参考文献:参见Bug #20646496。
NDB集群api:
Ndb: pollEvents ()
而且pollEvents2 ()
接收事件较慢,依赖于其他客户机线程或块代表它们执行传输器轮询。此修正允许客户端线程在必须在这些方法中等待时执行自己的传输器轮询。传输轮询的引入还揭示了一个问题,即在
ndbcluster_binlog
处理程序,该处理程序已作为此修复的一部分添加。(Bug #79311, Bug #20957068, Bug #22224571)在调试版本中,a
WAIT_EVENT
而轮询导致过多的日志记录到标准输出。(错误# 22203672)当执行模式操作时,例如
创建表
在有多个SQL节点的MySQL NDB集群中,执行操作的SQL节点可能在等待其他节点的确认时超时。当不同的SQL节点具有不同的设置时,可能会发生这种情况——ndb-log-updated-only
,——ndb-log-update-as-write
或其他mysqld影响二进制日志记录的选项NDB
.发生这种情况的原因是,为了在它们之间分布模式更改,所有SQL节点都订阅
ndb_schema
系统表,并且所有SQL节点都通过订阅来知道彼此的订阅TE_SUBSCRIBE
而且TE_UNSUBSCRIBE
事件。要订阅的事件的名称由表名构造,添加REPL美元
或REPLF美元
作为一个前缀。REPLF美元
在为表指定完整二进制日志记录时使用。前面所描述的问题的出现,是因为所提到的选项的不同值可能导致不同的SQL节点订阅不同的事件,这意味着所有SQL节点不一定相互知道,因此处理等待模式分发完成的代码没有按照设计的方式工作。为了解决这个问题,MySQL NDB集群现在处理
ndb_schema
表作为一个特殊情况,并强制在任何时候对该表进行完整的二进制日志记录,独立于任何设置mysqld二进制日志记录选项。(Bug #22174287, Bug #79188)试图创建一个
NDB
表的宽度大于所有表所支持的最大组合宽度位
当用定义列时,列(4096)会导致数据节点故障COLUMN_FORMAT动态
.(错误# 21889267)创建一个表,其中包含最大支持的列数(512)
COLUMN_FORMAT动态
导致数据节点故障。(错误# 21863798)使用ndb_mgm
停止- f
为了强制一个节点关闭,即使它触发了集群的完全关闭,当关闭足够数量的节点时,可能会丢失数据,从而触发集群关闭,时间是这样的SUMA
已经向已经处于关闭过程中的节点进行了交接。(错误# 17772138)内部
NdbEventBuffer: set_total_buckets ()
方法计算的剩余桶数不正确。这导致任何不完整的纪元被过早地完成SUB_START_CONF
信号到达时出现故障。随后到达的属于此阶段的任何事件都被忽略,从而有效地丢失,这导致模式更改不能正确地分布在SQL节点之间。(Bug #79635, Bug #22363510)在SUSE Linux Enterprise Server 12上编译MySQL NDB集群失败。(Bug #79429, Bug #22292329)
与非模式事件相比,模式事件被无序地追加到二进制日志中。这是因为二进制日志注入器没有正确处理模式事件和非模式事件来自不同时代的情况。
此修复修改了对来自两个模式和非模式事件流的事件的处理,这样事件现在总是每次处理一个纪元,从最老的可用纪元的事件开始,而不考虑它们发生在哪个事件流中。(Bug #79077, Bug #22135584, Bug #20456664)
NDB
由于设置了当前本地检查点的状态但不是活动的,在节点重启期间失败,尽管在这种条件下它可能有其他状态。(Bug #78780, Bug #21973758)设置的值。
spintime
由ThreadConfig
参数计算不正确,导致自旋持续的时间超过实际指定的时间。(Bug #78525, Bug #21886476)