引言
Galera Cluster是基于MySQL/innodb二次开发而成的一个支持“多主同步”的数据库主从集群。强调主从集群意味着Galera Cluster的每个节点充当一个数据冗余,而没有在节点间做分库分表的水平扩展。Galaer官网中为Galera Cluster洋洋洒洒罗列了10大优势,其实总结下来无非上文用引号注明的两点:
多主
Galera Cluster没有MySQL主从集群只有一个主能提供写服务的限制,集群中每个节点都可读可写,无需读写分离。在一个Galera Cluster前直接部署HAProxy或LVS做读写负责均衡是比较常用的做法。
同步
Galera replication具有实时性,能够保障不同节点的数据视图在较小的时间范围内是一致的。MySQL原生replication方案slave中的SQL线程和IO线程是分离的,即便使用半同步甚至同步复制,也可能因为SQL线程的速度跟不上IO线程而导致slave数据落后很多,当然5.7引入并行复制后会好很多,而Galera中除了具有并行复制的功能外,还具有flow control的功能来控制节点间数据同步的速度。
Galera Cluster相较于MySQL 来说的核心贡献是基于Galera replication plugin实现实现了多主和同步两大特性,本文将详细剖析Galera在解决多主和同步两大问题上的想法和思路。
架构简述
Galera Cluster节点间通过wsapi进行数据通信和同步,如图1和图2所示,wsapi通过hook的方式侵入Innodb中事务的commit流程,获取事务内所有数据行的更改,构造一个write set并将其同步到Cluster其他节点,wsapi即write set api简称。
图1. Galera Overview
图2. Galera library
Galera provider目前是wsapi的唯一实现。Galera provider内部实现又划分为多个层次,其中最为核心的是认证层(certification)和复制层(replication)。认证层负责检测本机事务,以及从其他节点同步来的事务是否可以提交,Galera的基于认证的事务乐观并发控制会在多主实现一节中介绍。复制层的工作包含两方面:
复制层通过组通信(Group communication)完成writeset的同步和GTID的分配,GTID的分配是Galera基于认证的事务并发控制和并行复制的前提和基础。
GTID与组通信
GTID是global transaction id的缩写,在MySQL社区中,GTID的概念并不新鲜,MySQL中的GTID是由Master生成,用于标志事务唯一性并通过ID定位binlog位置的一种手段,从而有效解决了级联复制等场景中的各种问题。
对于Galera Cluster来说,replication通过Galera replication中间件来保障,不基于binlog,因此Galera的GTID虽然也标志事务的唯一性,但是它的设计初衷完全不同,在介绍它的设计目的之前,先来看下Galera的GTID格式:
45eec521-2f34-11e0-0800-2a36050b826b:94530586304
如上图所示,GTID包含两部分:
而且实现方式也要复杂的多,因为Galera Cluster中所有节点都可做master,因此不能由一个节点随意去分配。理论上需要所有节点对一个事务的ID达成一致才能确定,但是这里引入Paxos一类的分布式一致性算法显然会严重拖慢commit速度,因为Paxos采用的是全同步的通信方式。