Galera Cluster 的局限以及它所不适应的场合

Galera Cluster 是主流的MySQL 多活多主高可用方案之一,即使在 InnoDB Cluster (Group Replication)发布以后。

Galera Cluster 是主流的MySQL 多活多主高可用方案之一,即使在 InnoDB Cluster (Group Replication)发布以后。

Galera Cluster 是主流的MySQL 多活多主高可用方案之一,即使在 InnoDB Cluster (Group Replication)发布以后。

重要的话说三遍:)

然而 Galera Cluster 所采用的技术方案,以及它所依赖的一些技术,使得它在标准的MySQL基础上有一些限制。

首先,它只支持 InnoDB系列的引擎。这对于很多应用而言不是大的问题。InnoDB是最广泛使用的MySQL 引擎, Group Replication 也是要求InnoDB。

第二,它不支持XA分布式事务协议。XA分布式事务协议,在传统的企业应用中很常用,特别是Java EE应用中。这一条对于遗留Java系统而言是个问题。

第三,它不支持表级锁。因此,不能使用Lock tables等与锁表相关的命令或函数。原因是Galera Cluster 底层的 write set 技术,是基于行的。

第四,它可能导致较多的冲突。在写集中如果有两个事务要改同一行数据,那么第二个事务会被中止。在收到异常消息后,应用应该重新发起该事务。这意味着应用程序的代码中,应该注意处理这种情况。实际中可以设置为单主同步复制模式,避免多主冲突;通过读写分离来利用只读节点资源。

第五,不要使用字符集 UTF-16, UTF-32. UCS-2。因为底层的rsync技术不支持这些字符集,影响了基于rsync的全量复制。大部分应用都是使用的UTF-8,因此问题并不大。

第六,表一定要有主键。如果没有主键,可以加一个自增长的主键,因此不是大问题。

第七,binlog不要试图去binlog-do-db, binlog-ignore-db。因为binlog的这几个选项只是支持了dml,不支持ddl,这可能导致binlog的复制过程中止。

第八,同步复制技术对于有明显热点或高并发的应用而言,容易产生冲突。与第四点相关。

第九,同步复制技术对于网络稳定性要求高(针对跨机房的集群要注意)。对于每一个查询(MySQL把所有的任务都叫查询)事务,都会有多节点的复制和冲突检测。从这个角度来说,它使得每次查询都变得慢一些(增加了延迟 latency)。

第十,使用 Galera Cluster 的上述限制,意味着需要与应用开发团队密切的合作,以便尽快发现应用代码中的数据库操作相关语句或逻辑是否正好碰到了 Galera Cluster的限制。

尽管有这么多的限制,Galera Cluster 仍然是最广泛使用的 MySQL 高可用方案之一。Galera Cluster最宝贵的就是其自动化程度高的高可用特性。这种强一致性、高可用的方案对于关键记录处理系统而言是非常重要的。