Galera Cluster原理

1、简介

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

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

2、基于认证的复制

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

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

3、内部架构

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

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

4、数据复制方式

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

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

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

一、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要快，但限制也挺多的。

二、Incremental State Transfers (IST)

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

• 一、新加入节点的state UUID须要与集群的一致（能够用show status like '%wsrep%'命令进行确认）；
• 二、全部落后的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。此值设置过大太小都很差，须要根据本身环境来合理设置。