Galera Cluster原理

猫哥

一、简介

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

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

二、基于认证的复制

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

clipboard.png

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

三、内部架构

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

clipboard.png

主要有以下几个组件组成:
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。此值设置过大过小都不好,需要根据自己环境来合理设置。

阅读 9.8k

数据库
数据库原理与实践

技术小白的打怪升级之路......

13 声望
4 粉丝
0 条评论
你知道吗?

技术小白的打怪升级之路......

13 声望
4 粉丝
文章目录
宣传栏