Galera：多主同步MySQL集群原理解析

转：Galera：多主同步MySQL集群原理解析

http://www.liuhaihua.cn/archives/44038.html

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简称。

Galera provider目前是wsapi的唯一实现。Galera provider内部实现又划分为多个层次，其中最为核心的是认证层（certification）和复制层（replication）。认证层负责检测本机事务，以及从其他节点同步来的事务是否可以提交，Galera的基于认证的事务乐观并发控制会在多主实现一节中介绍。复制层的工作包含两方面：

组通信，与其他节点同步writeset，并为事务分配全局唯一的GTID
并行复制，结合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包含两部分：

UUID，标志事务的唯一性ID
一个顺序ID，标志这个事务在Galera Cluster所有节点事务中的顺序
而且实现方式也要复杂的多，因为Galera Cluster中所有节点都可做master，因此不能由一个节点随意去分配。理论上需要所有节点对一个事务的ID达成一致才能确定，但是这里引入Paxos一类的分布式一致性算法显然会严重拖慢commit速度，因为Paxos采用的是全同步的通信方式。

PS：如果您想和业内技术大牛交流的话，请加qq群(527933790)或者关注微信公众 号(AskHarries)，谢谢！

===============

一、MariaDB Galera Cluster概要：

1.简述：
MariaDB Galera Cluster 是一套在mysql innodb存储引擎上面实现multi-master及数据实时同步的系统架构，业务层面无需做读写分离工作，数据库读写压力都能按照既定的规则分发到 各个节点上去。在数据方面完全兼容 MariaDB 和 MySQL。
2.特性：
(1).同步复制 Synchronous replication
(2).Active-active multi-master 拓扑逻辑
(3).可对集群中任一节点进行数据读写
(4).自动成员控制，故障节点自动从集群中移除
(5).自动节点加入
(6).真正并行的复制，基于行级
(7).直接客户端连接，原生的 MySQL 接口
(8).每个节点都包含完整的数据副本
(9).多台数据库中数据同步由 wsrep 接口实现
3.局限性
(1).目前的复制仅仅支持InnoDB存储引擎,任何写入其他引擎的表，包括mysql.*表将不会复制,但是DDL语句会被复制的,因此创建用户将会被复制,但是insert into mysql.user…将不会被复制的.
(2).DELETE操作不支持没有主键的表,没有主键的表在不同的节点顺序将不同,如果执行SELECT…LIMIT… 将出现不同的结果集.
(3).在多主环境下LOCK/UNLOCK TABLES不支持,以及锁函数GET_LOCK(), RELEASE_LOCK()…
(4).查询日志不能保存在表中。如果开启查询日志，只能保存到文件中。
(5).允许最大的事务大小由wsrep_max_ws_rows和wsrep_max_ws_size定义。任何大型操作将被拒绝。如大型的LOAD DATA操作。
(6).由于集群是乐观的并发控制，事务commit可能在该阶段中止。如果有两个事务向在集群中不同的节点向同一行写入并提交，失败的节点将中止。对 于集群级别的中止，集群返回死锁错误代码(Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)).
(7).XA事务不支持，由于在提交上可能回滚。
(8).整个集群的写入吞吐量是由最弱的节点限制，如果有一个节点变得缓慢，那么整个集群将是缓慢的。为了稳定的高性能要求，所有的节点应使用统一的硬件。
(9).集群节点建议最少3个。
(10).如果DDL语句有问题将破坏集群。