Galera Cluster原理

一、简介

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。此值设置过大过小都不好，需要根据自己环境来合理设置。