知识分享 | MariaDB Galera Cluster 和 Percona XtraDB Cluster之Galera replicateion数据同步方案

最近一系统架构要用到MariaDB Galera Cluster，故了解下其数据同步复制原理Galera replicateion。

本文节选自如下链接：
https://blog.csdn.net/qq_38125183/article/details/80861925

文章如下：

Galera replication是什么？
MySQL DBA及开发应该都知道MySQL源生复制及semi-sync半同步复制，它们都基于MySQL binlog，原生复制是完全异步的，master不需要保证slave接收并执行了binlog，能够保证master最大性能，但是slave可能存在延迟，主备数据无法保证一致性，在不停服务的前提下如果master宕机让slave顶上，就会丢失数据，semi-sync在异步复制基础上增加了数据保护的考虑，master必须确认slave收到binlog后（但不保证slave执行了事务）才能最终提交事务，在没有退化（延迟较大时可能发生）成异步复制之前可以保证数据安全，此时master挂掉之后，slave可以在apply完所有relay log后切换成master提供读写服务。

Galera replication是codership提供的MySQL数据同步方案，具有高可用，易于扩展等特点，它将多个MySQL节点组织成一个cluster。

Galera replication特性

1. 同步复制，主备无延迟
2. 支持多主同时读写，保证数据一致性
3. 集群中各节点保存全量数据
4. 节点添加/删除，自动检测和配置
5. 行级别并行复制
6. 不需要写binlog

相对于MySQL源生复制和semi-sync，Galera replication比较有吸引力的特性：

1. 同步复制，主备无延迟，master宕机后slave可以立即顶上并提供服务（semi-sync需要apply完所有relay log）
2. 事务冲突检测保证数据一致性，多个节点可以同时读写数据，可以极大简化数据访问
3. 行级别并行复制，MySQL 5.6之前slave sql线程只有一个，这个长期饱受诟病，是导致slave落后master的主要原因。

Galera replicateion限制

1. 集群至少3个节点（2个节点也可以运行）
2. 存储引擎：Innodb / XtraDB / Maria
3. 不支持的SQL：LOCK / UNLOCK TABLES / GET_LOCK(), RELEASE_LOCK()…
4. 不支持XA Transaction
   目前可用的产品：MariaDB Galera Cluster 和 Percona XtraDB Cluster

Galera replication原理
Galera replication是一种Certification based replication，保证one-copy serializability，理论基于这两篇论文：Don’t be lazy, be consistent 和 Database State Machine Approach

算法伪代码(Certification包含了后续流程，来自上面两篇论文Don’t be lazy, be consistent 和 Database State Machine Approach)

事务执行协议
遵守deferred update replication，事务在commit时才复制到其他节点，执行过程分为4个阶段：

1. Local read phase a) 本地（client连接到的节点）执行事务Ti，但不真正提交，真正提交之前进入Send phase
   2．Send phase a) 若事务只读，直接提交，结束（多版本，只读事务不加锁） b) 将事务的写操作封装成WS（Write Set，基于行），广播到所有节点（包括自身）
   3．Lock / Certificaion phase a) 对收到的WS中的每个WSi(X) i. 若X没有被加锁，对X加锁 ii. 若X已被Tj加锁且Tj处于Local read phase/Send phase，回滚Tj，对X加锁 iii. Certification based conflict detect
   4．Write phase a) 若检测出冲突，回滚Ti b) 否则，执行WS，提交事务后释放锁资源 c) 对于源节点，提交事务并向client返回结果

客户端/Galera节点信息交互图

Galera replication采取的是乐观策略，即事务在一个节点提交时，被认为与其他节点上的事务没有冲突，首先在本地“执行”（之所以带引号，是因为事务没有执行完）后再发送到所有节点做冲突检测，存在两种情况下需要回滚事务：

1. WS复制到其它节点，被加到每个节点的slave trx queue中，与queue中前面的trxs在做certification test时发现冲突；
2. WS通过了certification test后被保证一定会执行，在它执行过程中，如果该节点上有与其冲突的local trxs(Local phase)，回滚local trxs
   Galera提供了两个状态参数记录冲突：
   wsrep_local_cert_failures：certification test中未通过的trx数目
   wsrep_local_bf_aborts：apply trxs（已经通过certification test）时，回滚的local trxs（open but not commit）数目。

因此事务在commit节点广播后，节点之间不交换“是否冲突”的信息，各个节点独立异步的处理该事务，certification based replication协议保证：

1. 事务在所有节点上要么都commit，要么都rollback/abort
2. 事务在所有节点的执行顺序一致

Certification based replication所依赖的基础技术：
Group Communication System

1. Atomic delivery (事务传输要么成功传给了所有节点，要么都失败)
2. Total order (事务在所有节点中的顺序一致)
3. Group maintenance (每个节点知道所有节点的状态)

传统的2PC（两阶段提交）：

1. 2PC 事务结束时，所有节点数据达到一致
2. 协调者与参与者之间通信，参与者之间无连接
3. 受网络状态影响较大
4. 两次通信，需要得到每个参与者的反馈后才能决定是否提交事务

因此Galera replicateion相对于2PC减少了网络传输次数，消除了等待节点返回“决定是否冲突”的时间，从而可以提高了性能

Galera replication原理总结

1. 事务在本地节点执行时采取乐观策略，成功广播到所有节点后再做冲突检测
2. 检测出冲突时，本地事务优先被回滚
3. 每个节点独立、异步执行队列中的WS
4. 事务T在A节点执行成功返回客户端后，其他节点保证T一定会被执行，因此有可能存在延迟，即虚拟同步
   

Galera flow control
galera是同步复制（虚拟同步）方案，事务在本地节点（客户端提交事务的节点）上提交成功时，其它节点保证执行该事务。在提交事务时，本地节点把事务复制到所有节点后，之后各个节点独立异步地进行certification test、事务插入待执行队列、执行事务。然而由于不同节点之间执行事务的速度不一样，长时间运行后，慢节点的待执行队列可能会越积越长，最终可能导致事务丢失。

galera内部实现了flow control，作用就是协调各个节点，保证所有节点执行事务的速度大于队列增长速度，从而避免丢失事务。实现原理和简单：整个galera cluster中，同时只有一个节点可以广播消息（数据），每个节点都会获得广播消息的机会（获得机会后也可以不广播），当慢节点的待执行队列超过一定长度后，它会广播一个FC_PAUSE消息，所以节点收到消息后都会暂缓广播消息，直到该慢节点的待执行队列长度减小到一定长度后，galera cluster数据同步又开始恢复

flow control相关参数：
1.gcs.fc_limit：待执行队列长度超过该值时，flow control被触发，对于Master-Slave模式(只在一个节点写)的galera cluster，可以配置一个较大的值，对启动多写的galera cluster，较小的值比较合适，因为较大待执行队列长度意味着更大的冲突，默认值16；
2.gcs.fc_factor：当待执行队列长度开始小于(gcs.fc_factor*gcs.fc_limit)时，数据同步恢复,默认0.5；
3.gcs.fc_master_slave：galera cluster是否为Master-Slave模式，默认。

galera是同步复制（虚拟同步）方案，事务在本地节点（客户端提交事务的节点）上提交成功时，其它节点保证执行该事务。在提交事务时，本地节点把事务复制到所有节点后，之后各个节点独立异步地进行certification test、事务插入待执行队列、执行事务。然而由于不同节点之间执行事务的速度不一样，长时间运行后，慢节点的待执行队列可能会越积越长，最终可能导致事务丢失。

galera内部实现了flow control，作用就是协调各个节点，保证所有节点执行事务的速度大于队列增长速度，从而避免丢失事务。实现原理和简单：整个galera cluster中，同时只有一个节点可以广播消息（数据），每个节点都会获得广播消息的机会（获得机会后也可以不广播），当慢节点的待执行队列超过一定长度后，它会广播一个FC_PAUSE消息，所以节点收到消息后都会暂缓广播消息，直到该慢节点的待执行队列长度减小到一定长度后，galera cluster数据同步又开始恢复。

mariadb galera可实现数据库的多主模式（默认为master-slave,单主模式）；
该模式是通过在写数据的时候，确保数据写入到所有服务器中之后才认为该写入操作成功，所以其能够基本保持数据的一致性以及数据操作的原子性。并且其不存在mysql主从中的不能在从上面写入数据的原则，在所有服务器上面都可以写入数据，其会自动同步到所有服务器中。

mariadb galera的的缺点；

1. 其写入数据的性能是由集群中最差的一台服务器来决定的，所以在生产环境中需要尽量保持集群中的所有服务器软硬件配置一样，从而避免所谓的木桶原理影响性能。2. 还有就是mariadb galera只能使用innodb存储引擎，而不能使用其他存储引擎，并且不支持锁表操作。

文章结束。

以下为个人公众号，欢迎扫码关注：