一种新型的高一致性MySQL集群架构：Galera Cluster

原文地址：https://www.linuxprobe.com/galera-cluster.html?spm=a2c4e.11153987.0.0.17312a34IBHu4a

1. 何谓Galera Cluster

何谓Galera Cluster？就是集成了Galera插件的MySQL集群，是一种新型的，数据不共享的，高度冗余的高可用方案，目前Galera Cluster有两个版本，分别是Percona Xtradb Cluster及MariaDB Cluster，都是基于Galera的，因此这里都统称为Galera Cluster了，由于Galera自己是具备多主特性的，因此Galera Cluster也就是multi-master的集群架构，如图1所示：

图1 Galera Cluster架构

图1中有三个实例，组成了一个集群，而这三个节点与普通的主从架构不一样，它们均可以做为主节点，三个节点是对等的，这种通常称为multi-master架构，当有客户端要写入或者读取数据时，随便链接哪一个实例都是同样的，读到的数据是相同的，写入某一个节点以后，集群本身会将新数据同步到其它节点上面，这种架构不共享任何数据，是一种高冗余架构。

通常的使用方法是，在这个集群上面，再搭建一个中间层，这个中间层的功能包括创建链接、管理链接池，负责使三个实例的负载基本平衡，负责在客户端与实例的链接断开以后重连，也能够负责读写分离（在机器性能不一样的状况下能够作这样的优化）等等，使用这个中间层以后，因为这三个实例的架构在客户端方面是透明的，客户端只须要指定这个集群的数据源地址，链接到中间层便可，中间层会负责客户端与服务器实例链接的传递工做，因为这个架构支持多点写入，因此彻底避免了主从复制常常出现的数据不一致的问题，从而能够作到主从读写切换的高度优雅，在不影响用户的状况下，离线维护等工做，MySQL的高可用，今后开始，很是完美。

2. 为何须要Galera Cluster

MySQL在互联网时代，可谓是深受世人瞩目的。给社会创造了无限价值，随之而来的是，在MySQL基础之上，产生了形形×××的使用方法、架构及周边产品。本文所关注的是架构，在这方面，已经有不少成熟的被人熟知的产品，好比MHA、MMM等传统组织架构，而这些架构是每一个须要数据库高可用服务方案的入门必备选型。

不幸的是，传统架构的使用，一直被人们所诟病，由于MySQL的主从模式，天生的不能彻底保证数据一致，不少大公司会花很大人力物力去解决这个问题，而效果却通常，能够说，只能是经过牺牲性能，来得到数据一致性，但也只是在下降数据不一致性的可能性而已。因此如今就急需一种新型架构，从根本上解决这样的问题，天生的摆脱掉主从复制模式这样的“美中不足”之处了。

幸运的是，MySQL的福音来了，Galera Cluster就是咱们须要的——今后变得完美的架构。

相比传统的主从复制架构，Galera Cluster解决的最核心问题是，在三个实例（节点）之间，它们的关系是对等的，multi-master架构的，在多节点同时写入的时候，可以保证整个集群数据的一致性，完整性与正确性。

在传统MySQL的使用过程当中，也不难实现一种multi-master架构，可是通常须要上层应用来配合，好比先要约定每一个表必需要有自增列，而且若是是2个节点的状况下，一个节点只能写偶数的值，而另外一个节点只能写奇数的值，同时2个节点之间互相作复制，由于2个节点写入的东西不一样，因此复制不会冲突，在这种约定之下，能够基本实现多master的架构，也能够保证数据的完整性与一致性。但这种方式使用起来仍是有限制，同时还会出现复制延迟，而且不具备扩展性，不是真正意义上的集群。

3. Galera Cluster如何解决问题

3.1 Galera的引入

如今已经知道，Galera Cluster是MySQL封装了具备高一致性，支持多点写入的同步通讯模块Galera而作的，它是创建在MySQL同步基础之上的，使用Galera Cluster时，应用程序能够直接读、写某个节点的最新数据，而且能够在不影响应用程序读写的状况下，下线某个节点，由于支持多点写入，使得Failover变得很是简单。

全部的Galera Cluster，都是对Galera所提供的接口API作了封装，这些API为上层提供了丰富的状态信息及回调函数，经过这些回调函数，作到了真正的多主集群，多点写入及同步复制，这些API被称做是Write-Set Replication API，简称为wsrep API。

经过这些API，Galera Cluster提供了基于验证的复制，是一种乐观的同步复制机制，一个将要被复制的事务（称为写集），不只包括被修改的数据库行，还包括了这个事务产生的全部Binlog，每个节点在复制事务时，都会拿这些写集与正在APPLY队列的写集作比对，若是没有冲突的话，这个事务就能够继续提交，或者是APPLY，这个时候，这个事务就被认为是提交了，而后在数据库层面，还须要继续作事务上的提交操做。

这种方式的复制，也被称为是虚拟同步复制，其实是一种逻辑上的同步，由于每一个节点的写入和提交操做仍是独立的，更准确的说是异步的，Galera Cluster是创建在一种乐观复制的基础上的，假设集群中的每一个节点都是同步的，那么加上在写入时，都会作验证，那么理论上是不会出现不一致的，固然也不能这么乐观，若是出现不一致了，好比主库（相对）插入成功，而从库则出现主键冲突，那说明此时数据库已经不一致，这种时候Galera Cluster采起的方式是将出现不一致数据的节点踢出集群，实际上是本身shutdown了。

而经过使用Galera，它在里面经过判断键值的冲突方式实现了真正意义上的multi-master，Galera Cluster在MySQL生态中，在高可用方面实现了很是重要的提高，目前Galera Cluster具有的功能包括以下几个方面：

多主架构：真正的多点读写的集群，在任什么时候候读写数据，都是最新的。
同步复制：集群不一样节点之间数据同步，没有延迟，在数据库挂掉以后，数据不会丢失。
并发复制：从节点在APPLY数据时，支持并行执行，有更好的性能表现。
故障切换：在出现数据库故障时，由于支持多点写入，切的很是容易。
热插拔：在服务期间，若是数据库挂了，只要监控程序发现的够快，不可服务时间就会很是少。在节点故障期间，节点自己对集群的影响很是小。
自动节点克隆：在新增节点，或者停机维护时，增量数据或者基础数据不须要人工手动备份提供，Galera Cluster会自动拉取在线节点数据，最终集群会变为一致。
对应用透明：集群的维护，对应用程序是透明的，几乎感受不到。 以上几点，足以说明Galera Cluster是一个既稳健，又在数据一致性、完整性及高性能方面有出色表现的高可用解决方案。
不过在运维过程当中，有些技术特色仍是须要注意的，这样才能作到知此知彼，百战百胜，由于如今MySQL主从结构的集群已经都是被你们所熟知的了，而Galera Cluster是一个新的技术，是一个在不断成熟的技术，因此不少想了解这个技术的同窗，可以获得的资料不多，除了官方的手册以外，基本没有一些讲得深刻的，用来传道授业解惑的运维资料，这无疑为不少同窗设置了不低的门槛，最终有不少人由于一些特性，致使最终放弃了Galera Cluster的选择。

目前熟知的一些特性，或者在运维中须要注意的一些特性，有如下几个方面：

Galera Cluster写集内容：Galera Cluster复制的方式，仍是基于Binlog的，这个问题，也是一直被人纠结的，由于目前Percona Xtradb Cluster所实现的版本中，在将Binlog关掉以后，仍是可使用的，这误导了不少人，其实关掉以后，只是不落地了，表象上看上去是没有使用Binlog了，实际上在内部仍是悄悄的打开了的。除此以外，写集中还包括了事务影响的全部行的主键，全部主键组成了写集的KEY，而Binlog组成了写集的DATA，这样一个KEY-DATA就是写集。KEY和DATA分别具备不一样的做用的，KEY是用来验证的，验证与其它事务没有冲突，而DATA是用来在验证经过以后，作APPLY的。
Galera Cluster的并发控制：如今都已经知道，Galera Cluster能够实现集群中，数据的高度一致性，而且在每一个节点上，生成的Binlog顺序都是同样的，这与Galera内部，实现的并发控制机制是分不开的。全部的上层到下层的同步、复制、执行、提交都是经过并发控制机制来管理的。这样才能保证上层的逻辑性，下层数据的完整性等。

图2 galera原理图

图2是从官方手册中截取的，从图中能够大概看出，从事务执行开始，到本地执行，再到写集发送，再到写集验证，再到写集提交的整个过程，以及从节点（相对）收到写集以后，所作的写集验证、写集APPLY及写集提交操做，经过对比这个图，能够很好的理解每个阶段的意义及性能等，下面就每个阶段以及其并发控制行为作一个简单的介绍：
a. 本地执行：这个阶段，是事务执行的最初阶段，能够说，这个阶段的执行过程，与单点MySQL执行没什么区别，并发控制固然就是数据库的并发控制了，而不是Galera Cluster的并发控制了。

b. 写集发送：在执行完以后，就到了提交阶段，提交以前首先将产生的写集广播出去，而为了保证全局数据的一致性，在写集发送时，须要串行，这个就属于Galera Cluster并发控制的一部分了。

c. 写集验证：这个阶段，就是咱们一般说的Galera Cluster的验证了，验证是将当前的事务，与本地写集验证缓存集来作验证，经过比对写集中被影响的数据库KEYS，来发现有没有相同的，来肯定是否是能够验证经过，那么这个过程，也是串行的。

d. 写集提交：这个阶段，是一个事务执行时的最后一个阶段了，验证完成以后，就能够进入提交阶段了，由于些时已经执行完了的，而提交操做的并发控制，是能够经过参数来控制其行为的，即参数repl.commit_order，若是设置为3，表示提交就是串行的了，而这也是本人所推荐的（默认值）的一种设置，由于这样的结果是，集群中不一样节点产生的Binlog是彻底同样的，运维中带来了很多好处和方便。其它值的解释，之后有机会再作讲解。

e. 写集APPLY：这个阶段，与上面的几个在流程上不太同样，这个阶段是从节点作的事情，从节点只包括两个阶段，即写集验证和写集APPLY，写集APPLY的并发控制，是与参数wsrep_slave_threads有关系的，自己在验证以后，肯定了相互的依赖关系以后，若是肯定没有关系的，就能够并行了，而并行度，就是参数wsrep_slave_threads的事情了。wsrep_slave_threads能够参照参数wsrep_cert_deps_distance来设置。

3.2 流量控制

在PXC中，有一个参数叫fc_limit，它的全名实际上是叫flow control limit，顾名思义，是流量控制大小限制的意思，它的做用是什么呢？

若是一套集群中，某个节点，或者某几个节点的硬件资源比较差，或者因为节点压力大，致使复制效率低下，等等各类缘由，致使的结果是，从节点APPLY时，很是慢，也就是说，主库在一秒钟以内作的操做，从库有可能会用2秒才能完成，那么这种状况下，就会致使从节点执行任务的堆积，接收队列的堆积。

假设从节点真的堆积了，那么Galera会让它一直堆积下去么？这样延迟会愈来愈严重，这样Galera Cluster就变成一个主从架构的集群了，已经失去了强一致状态的属性了，那么很明显，Galera是不会让这种事情发生的，那么此时，就说回到开头提到的参数了，gcs.fc_limit，这个参数是在MySQL参数wsrep_provider_options中来配置的，这个参数是Galera的一个参数集合，有关于Flow Control的，还包括gcs.fc_factor，这两个参数的意义是，当从节点堆积的事务数量超过gcs.fc_limit的值时，从节点就发起一个Flow Control，而当从节点堆积的事务数小于gcs.fc_limit * gcs.fc_factor时，发起Flow Control的从节点再发起一个解除的消息，让整个集群再恢复。

但咱们通常所关心的，就是如何解决，下面有几个通常所采用的方法：

发送FC消息的节点，硬件有可能出现问题了，好比IO写不进去，很慢，CPU异常高等
发送FC消息的节点，自己数据库压力过高，好比当前节点承载太多的读，致使机器Load高，IO压力大等等。
发送FC消息的节点，硬件压力都没有太大问题，但作得比较慢，通常缘由是主库并发高，但从节点的并发跟不上主库，那么此时可能须要观察这两个节点的并发度大小，能够参考状态参数wsrep_cert_deps_distance的值，来调整从节点的wsrep_slave_threads，此时应该是能够解决或者缓解的，这个问题能够这样去理解，假设集群每一个节点的硬件资源都是至关的，那么主库能够执行完，从库为何作不过来？那么通常思路就是像处理主从复制的延迟问题同样。
检查存不存在没有主键的表，由于Galera的复制是行模式的，因此若是存在这样的表时，主节点是经过语句来修改的，好比一个更新语句，更新了全表，而从节点收到以后，就会针对每一行的Binlog作一次全表扫描，这样致使这个事务在从节点执行，比在主节点执行慢十倍，或者百倍，从而致使从节点堆积进而产生FC。
能够看出，其实这些方法，都是用来解决主从复制延迟的方法，没什么两样，在了解Flow Control的状况下，解决它并非难事儿。

3.3 有不少坑？

有不少同窗，在使用过Galera Cluster以后，发现不少问题，最大的好比DDL的执行，大事务等，从而致使服务的不友好，这也是致使不少人放弃的缘由。

DDL执行卡死传说：使用过的同窗可能知道，在Galera Cluster中执行一个大的改表操做，会致使整个集群在一段时间内，是彻底写入不了任何事务的，都卡死在那里，这个状况确实很严重，致使线上彻底不可服务了，缘由仍是并发控制，由于提交操做设置为串行的，DDL执行是一个提交的过程，那么串行执行改表，固然执行多久，就卡多久，直到改表执行完，其它事务也就能够继续操做了，这个问题如今没办法解决，但咱们长期使用下来发现，小表能够这样直接操做，大一点或者更大的，都是经过osc（pt-online-schema-change）来作，这样就很好的避免了这个问题。
挡我者死：因为Galera Cluster在执行DDL时，是Total Ordered Isolation（wsrep_OSU_method=TOI）的，因此必需要保证每一个节点都是同时执行的，固然对于不是DDL的，也是Total Order的，由于每个事务都具备同一个GTID值，DDL也不例外，而DDL涉及到的是表锁，MDL锁（Meta Data Lock），只要在执行过程当中，遇到了MDL锁的冲突，全部状况下，都是DDL优先，将全部的使用到这个对象的事务，通通杀死，无论是读事务，仍是写事务，被杀的事务都会报出死锁的异常，因此这也是一个Galera Cluster中，关于DDL的闻名遐迩的坑。不过这个如今确实没有办法解决，也没办法避免，不过这个的影响还算能够接受，先能够忍忍。
不死之身：继上面的“挡我者死”，若是集群真的被一个DDL卡死了，致使整个集群都动不了了，全部的写请求都Hang住了，那么可能会有人想一个妙招，说赶忙杀死，直接在每一个节点上面输入kill connection_id，等等相似的操做，那么此时，很不肯意看到的信息报了出来：You are not owner of thread connection_id。此时可能有些同窗要哭了，不过这种状况下，确实没有什么好的解决方法（其实这个时候，一个故障已经发生了，一年的KPI也许已经没有了，就看敢不敢下狠手了），要不就等DDL执行完成（全部这个数据库上面的业务都处于不可服务状态），要不就将数据库直接Kill掉，快速重启，赶忙恢复一个节点提交线上服务，而后再考虑集群其它节点的数据增量的同步等，这个坑很是大，也是在Galera Cluster中，最大的一个坑，须要很是当心，避免出现这样的问题。

4. 适用场景

如今对Galera Cluster已经有了足够了解，但这样的“完美”架构，在什么场景下才可使用呢？或者说，哪一种场景又不适合使用这样的架构呢？针对它的缺点，及优势，咱们能够扬其长，避其短。能够经过下面几个方面，来了解其适用场景。

数据强一致性：由于Galera Cluster，能够保证数据强一致性的，因此它更适合应用于对数据一致性和完整性要求特别高的场景，好比交易，正是由于这个特性，咱们去哪儿网才会成为使用Galera Cluster的第一大户。
多点写入：这里要强调多点写入的意思，不是要支持以多点写入的方式提供服务，更重要的是，由于有了多点写入，才会使得在DBA正常维护数据库集群的时候，才会不影响到业务，作到真正的无感知，由于只要是主从复制，就不能出现多点写入，从而致使了在切换时，必然要将老节点的链接断掉，而后齐刷刷的切到新节点，这是没办法避免的，而支持了多点写入，在切换时刻容许有短暂的多点写入，从而不会影响老的链接，只须要将新链接都路由到新节点便可。这个特性，对于交易型的业务而言，也是很是渴求的。
性能：Galera Cluster，能支持到强一致性，毫无疑问，也是以牺牲性能为代价，争取了数据一致性，但要问：”性能牺牲了，会不会致使性能太差，这样的架构根本不能知足需求呢？”这里只想说的是，这是一个权衡过程，有多少业务，QPS大到Galera Cluster不能知足的？我想是很少的（固然也是有的，能够自行作一些测试），在追求很是高的极致性能状况下，也许单个的Galera Cluster集群是不能知足需求的，但毕竟是少数了，因此够用就好，Galera Cluster必然是MySQL方案中的佼佼者。

5. 总结

综上所述，Galera Cluster是一个彻底可依赖的，MySQL数据一致性的绝杀利器，使用中彻底不须要担忧数据延迟，数据不一致的问题，DBA今后就从繁复的数据修复、解决复制延迟、维护时担忧影响业务的问题中完全解脱了。能够说Galera Cluster是DBA及业务系统的福音，也是MySQL发展的大趋势，我但愿它会愈来愈好，也但愿也有愈来愈多的人使用它，共同维护这个美好的大环境。