一、简介

Galera Cluster是Codership公司开发的一套免费开源的高可用方案，官网为http://galeracluster.com。Galera Cluster即为安装了Galera的Mariadb集群（本文只介绍Mariadb Garela集群）。其本身具有multi-master特性，支持多点写入。Galera Cluster的三个（或多个）节点是对等关系，每个节点均支持写入，集群内部会保证写入数据的一致性与完整性，具体实现原理会在本篇中做简要介绍。
官方给出的特性如下：

真正的多主集群，Active-Active架构；
同步复制，没有复制延迟；
多线程复制；
没有主从切换操作，无需使用虚IP；
热备份，单个节点故障期间不会影响数据库业务；
支持节点自动加入，无需手动拷贝数据；
支持InnoDB存储引擎；
对应用程序透明，原生MySQL接口；
无需做读写分离；
部署使用简单。

二、基于认证的复制

有关同步复制与异步复制在此就不赘述了，介绍一下基于认证的复制方式。
工作原理如下：

当客户端提交一个commit命令，在事务提交之前，所有对数据库的操作都会被写入write-set中，包括主键，，然后数据库会将这个write-set发给所有其他节点，write-set将在每个节点（包括生成write-set的节点）上使用主键进行认证尝试。
如果认证失败，节点会丢弃这个write-set，同时集群会回滚到之前的事务点；如果认证成功，commit正常提交，事务会应用到其他节点上。
Galera Cluster基于认证的复制主要依赖于the global ordering of transactions，我们暂且称其为全局事务序号，复制期间，Galera Cluster会为每一个事务分配一个全局事务序号，类似序列号。当某个事务到达commit阶段时，节点会检查待提交事务的序号与上一次成功提交事务的序号，检查区间所有事务是否与新事务存在主键冲突，如果检查到冲突，认证就会失败。
所有节点以相同的顺序接受事务，所有节点对事务是否提交做一致性决定。事务提交成功之后，首先生成此事务的节点会通知应用程序事务已正确提交。

三、内部架构

数据同步使用同步复制（Eager Replication），集群中的节点通过更新单个事务来与集群中的节点进行同步，这意味着当事务进行提交时，所有节点都具有相同的值。
内部架构如下：

主要有以下几个组件组成：
DBMS：Database Management System，即我们常见的数据库，Galera Cluster支持MySQL、MariaDB和Percona XtraDB。
wsrep API：写集复制功能组件，负责提供关系型数据库管理、复制服务，提供接口。
Galera Replication Plugin：启用写集复制功能的插件。
Group Communication plugins：Galera Clsuter集群中各种群组通信系统，例如gcomm和Spread。

四、数据复制方式

将集群中的数据复制到某个节点上实现备份，或者节点新加入集群需要同步数据。
Galera Cluster有两种数据复制方式：

State Snapshot Transfers (SST)：全量同步
Incremental State Transfers (IST)：增量同步

简单来讲。SST就是同步整个数据库，IST是同步一个库与另一个库相差的部分事务。

1、State Snapshot Transfers (SST)

当一个节点新加入集群时，新加入的节点会向集群中已存在的某个节点开始进行全量同步，全量同步中有两种不同的方式：
Logical：这种方法其实就是常用的mysqldump。在同步之前需要同步的数据库需要初始化，即没有任何多余的数据。这是一种加锁的方式，传输期间，数据库会变成read-only，同时，同步的主库上会运行一个杀伤性比较大的FLUSH TABLES WITH READ LOCK命令。下面简单介绍一下这个命令，来看看为什么要说它杀伤力比较大。
FLUSH TABLES WITH READ LOCK命令简称FTWRL，该命令主要用于备份工具获取一致性备份，由于FTWRL命令总共需要持有两把全局MDL锁，并且还需要关闭所有表对象，所以会说它杀伤性比较大。执行此命令容易造成库hang住，如果在主库上执行此命令，容易造成业务异常，如果在备库上执行，容易造成SQL线程卡住，造成主备复制延迟。
Physical：这种方式使用rsync, rsync_wan, xtrabackup和其他一些方式直接将数据文件从一个节点复制到另一个节点上，简单粗暴！这种方式比mysqldump要快，但限制也挺多的。

2、Incremental State Transfers (IST)

这种复制方式会验证从库落后的事务，然后将这部分发送过去，而不是将整个数据库进行同步。
这种方式有两个限制：

1、新加入节点的state UUID需要与集群的一致（可以用show status like '%wsrep%'命令进行确认）；
2、所有落后的write-sets需要在主库的write-set cache中存在。

下面用个例子来简单介绍一下：
假设现在有一个节点赶不上集群的进度了，它的node state为

a76ef62-30ec-11e1-0800-dba504cf2aab:197222

同时，集群中的一个节点的note state为

5a76ef62-30ec-11e1-0800-dba504cf2aab:201913

主库（我们姑且这样称呼，比较好辨认）收到从库的同步请求之后，塔会在自己的write-set cache查找sequence number 197223，如果没有找着，就开始进行SST，如果能找着，主库就将197223到201913的commit同步给从库。
注意：从实现原理上，我们就能发现，write-set cache的大小将直接决定能进行多少增量复制，在主库上由gcache.size来决定使用多大的内存来存储write-sets。此值设置过大过小都不好，需要根据自己环境来合理设置。

Galera Cluster原理