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

1.什么是Galera星团

什么是Galera Cluster？与Galera插件集成的MySQL集群是一种新的、数据共享的、高度冗余和高度可用的解决方案。目前Galera Cluster有两个版本，Percona Xtradb Cluster和MariaDB Cluster，都是基于Galera的，所以这里都叫Galera Cluster。Galera Cluster是多主机的集群架构，因为Galera本身具有多主机的特性，如图1所示:

图1 Galera集群架构

图1中有三个实例，它们形成了一个集群。这三个节点不同于常见的主从架构，都可以作为主节点，三个节点是相等的。这种架构一般称为多主架构。当客户端想要写入或读取数据时，连接任何实例都是一样的，读取的数据也是一样的。写入某个节点后，集群会将新数据同步到其他节点。该架构不共享任何数据。

一般的使用方法是在这个集群上构建一个中间层。这个中间层的功能包括建立连接和管理连接池，负责基本平衡三个实例的负载，客户端和实例的连接断开后重新连接，还负责读写分离。使用这个中间层后，这三个实例的架构在客户端是透明的。客户端只需要指定这个集群的数据源地址，连接到中间层，中间层将负责客户端和服务器实例之间连接的传输。由于这种架构支持多点写入，完全避免了主从复制中经常出现的数据不一致问题，使得主从读写切换可以高度优雅，离线维护等工作可以在不影响用户的情况下完成，MySQL从此高度可用，非常完美。

2.为什么需要Galera Cluster

在互联网时代，MySQL已经引起了全世界的关注。它为社会创造了无限的价值，与之相伴，在MySQL的基础上出现了各种使用方法、架构和外围产品。本文主要研究建筑。在这方面，有许多成熟和知名的产品，如MHA、MMM和其他传统的组织架构，这些架构是每个需要数据库高可用性的服务方案的必要入口选择。

遗憾的是，传统架构的使用一直受到人们的批评，因为MySQL的主从模式不能完全保证数据一致性，很多大公司会花费大量的人力物力来解决这个问题，但效果一般。可以说，数据一致性只能通过牺牲性能来获得，但这只是降低了数据不一致的可能性。因此，迫切需要一种新的架构来从根本上解决这个问题，摆脱主从复制模式的“美中不足”。

好在MySQL的福音来了，Galera Cluster就是我们需要的——从此完美的架构。

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

在传统的MySQL使用中，实现多主架构并不难，但一般需要上层应用的配合。比如首先约定每个表必须有自增列，在两个节点的情况下，一个节点只能写偶数的值，另一个节点只能写奇数的值。同时，两个节点互相复制。因为两个节点写的东西不一样，所以复制不会冲突。在这个协议下，基本可以实现。但是这种方法使用受限，会有复制延迟，而且不可伸缩，所以不是真正的集群。

3.Galera Cluster如何解决问题3.1 Galera简介

现在我们知道Galera Cluster是用MySQL封装Galera做的，Galera是一个同步通信模块，一致性高，支持多点写入。是基于MySQL同步的。使用Galera Cluster时，应用程序可以直接读写一个节点的最新数据，也可以注销一个节点而不影响应用程序的读写。由于支持多点写入，故障转移变得非常简单。

所有Galera Cluster都封装了Galera提供的接口API。这些API为上层提供了丰富的状态信息和回调函数。通过这些回调函数，实现了真正的多主集群、多点写入和同步复制。这些应用编程接口被称为写集复制接口，简称wsrep接口。

通过这些API，Galera Cluster提供了基于验证的复制，这是一种乐观的同步复制机制。要复制的事务不仅包括已修改的数据库行，还包括由该事务生成的所有Binlog。当每个节点复制一个事务时，它会将这些写集与APPLY队列中的写集进行比较。如果没有冲突，此事务可以继续提交或应用。此时，该事务被视为已提交，然后在数据库级别，需要继续提交事务。

这种方式的复制也称为虚拟同步复制，实际上是一种逻辑同步，因为每个节点的写和提交操作是独立的，更准确地说是异步的。Galera Cluster基于乐观复制。假设集群中每个节点都是同步的，写的时候会做验证，理论上不会有不一致，当然也不会那么乐观。如果有不一致，比如主库插入成功，而从库有主键冲突，说明此时数据库已经不一致。在这种情况下，Galera Cluster采取的方法是从集群中踢出数据不一致的节点，但实际上是关闭自己。

利用Galera，通过判断键值冲突实现真正的多主。Galera Cluster在MySQL生态中实现了非常重要的高可用性提升。目前，Galera集群具有以下功能:

多主机架构:一个真正的多点集群，随时读写数据，是最新的。

同步复制:集群中不同节点之间的数据同步没有延迟，数据库挂起后不会丢失数据。

并发复制:从节点应用数据时，支持并行执行，性能更好。

故障转移:在数据库故障的情况下，切换非常容易，因为它支持多点写入。

热插拔:在服务期间，如果数据库挂起，只要监控器足够快地找到它，无法使用的时间就会非常小。在节点故障期间，节点本身对集群的影响很小。

自动克隆节点:添加新节点或停止维护时，不需要手动备份增量数据或基础数据，Galera Cluster会自动将节点数据拉在线上，最终使集群变得一致。

对应用透明:集群维护对应用透明，几乎察觉不到。以上几点足以说明Galera Cluster是一个高度可用的解决方案，它是健壮的，并且在数据一致性、完整性和高性能方面具有突出的性能。

但是在运维过程中，还是需要注意一些技术特性，这样才能互相了解，赢得每一场战斗，因为MySQL主从集群现在大家都很熟悉，而Galera Cluster是一种新技术，也是一种日趋成熟的技术，所以很多想了解这项技术的同学能得到的信息很少，除了官方的手册，基本上没有深入的信息。用来传道、授业、解惑的运维教材无疑给很多学生设置了很高的门槛，很多人最终因为一些特点而放弃了Galera Cluster的选择。

目前一些众所周知的特性，或者一些在操作和维护中需要注意的特性，有以下几个方面:

Galera Cluster写内容:Galera Cluster复制模式还是基于Binlog的，一直很纠结，因为在Percona Xtradb Cluster实现的当前版本中，Binlog关闭后还可以使用，误导了很多人。事实上，它关闭后，就是不着陆。表面上不使用Binlog，其实里面是悄悄打开的。此外，写入集还包括受事务影响的所有行的主键。所有主键构成写集的键，而Binlog构成写集的数据，因此键数据是写集。密钥和数据分别具有不同的功能。KEY用于验证，验证与其他事务不冲突，DATA用于验证通过后应用。

Galera Cluster的并发控制:众所周知Galera Cluster可以在集群中实现高度的数据一致性，生成的Binlog序列在每个节点上是相同的，这与Galera中实现的并发控制机制密不可分。从上层到下层的所有同步、复制、执行和提交都由并发控制机制管理。这样才能保证上层的逻辑和下层数据的完整性。

图2 galera原理图

图2摘自官方手册。从图中大致可以看出，从事务执行到本地执行，再到写集合发送，再到写集合验证，再到写集合提交的整个过程，以及从节点接收到写集合后执行的写集合验证、写集合APPLY、写集合提交操作。通过对比这个数字，我们可以很好的了解各个阶段的意义和表现等。

A.本地执行:这个阶段是事务执行的初始阶段。可以说这一阶段的执行过程和单点MySQL执行没有什么不同。并发控制当然是数据库的并发控制，而不是Galera Cluster的并发控制。

B.写集发送:执行完毕后，会进入提交阶段。提交之前，将首先广播生成的写入集。为了保证全局数据的一致性，需要串行发送写集合，这是Galera Cluster并发控制的一部分。

C.writeset验证:这个阶段就是我们通常所说的Galera Cluster验证。验证是用本地writeset验证缓存集验证当前事务，并找出writeset中受影响的数据库中是否有任何相同的KEYS，以确定验证是否可以通过。那么这个过程也是连续的。

D.写集合提交:这个阶段是事务执行的最后阶段。验证完成后，就可以进入提交阶段了，因为已经执行了一段时间，提交操作的并发控制可以通过参数控制其行为，也就是参数repl。提交订单。如果设置为3，则表示提交是串行的，这也是我推荐的之一，其他值的解释将在后面说明。

E.write set APPLY:就流程而言，这个阶段与上面的阶段非常不同。这个阶段由从节点完成，它只包括两个阶段，即写集验证和写集应用，写集应用的并发控制与参数wsrep_slave_threads有关。验证后，确定相互依赖关系后，如果确定没有关系，则可以并行。Wsrep_slave_threads可以参考参数wsrep_cert_deps_distance进行设置。

3.2 流量控制

在PXC中，有一个参数叫做fc_limit。它的全称实际上叫做流量控制极限。顾名思义，它意味着流量控制大小限制。它的功能是什么？

如果集群中某个节点或者几个节点的硬件资源很差，或者由于节点的压力导致复制效率低下等。，结果是从节点的APPLY非常慢，也就是说主库在一秒钟内完成的操作可能会在两秒钟内被从库完成。在这种情况下，它将导致从属节点执行的任务的累积和接收队列的累积

假设从节点真的堆积，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的从节点发起一个release消息，恢复整个集群。

但我们普遍关心的是如何解决。以下是一些常用的方法:

发送FC消息的节点可能存在硬件问题，比如IO写不进去，速度慢，CPU异常高

发送FC消息的节点数据库压力过大，比如当前节点携带读取太多，导致机器负载大，IO压力大。

发送FC消息的节点硬件压力不太大，但速度较慢。一般原因是主库并发性高，从节点并发性跟不上主库。此时，可能需要观察这两个节点的并发性。您可以通过参考状态参数wsrep_cert_deps_distance的值来调整从节点的wsrep_slave_threads。这个时候应该解决或者缓解。这个问题可以这样理解。假设集群中每个节点的硬件资源是等价的，那么就可以执行主库。为什么奴隶库做不到？总体思路是处理主从复制的延迟问题。

检查是否存在没有主键的表，因为Galera的复制是行模式，所以如果存在这样的表，主节点会通过一条语句对其进行修改，比如update语句，更新整个表。从从节点收到后，会扫描整个表寻找每一行的Binlog，导致事务在从节点执行，比主节点慢十倍甚至百倍，从而导致从节点堆积生成FC。

可见，其实这些方法都是用来解决主从复制延迟的，没什么区别，理解流控也不难解决。

3.3坑多？

很多同学，在使用Galera Cluster后，发现了很多问题，比如DDL执行，大生意等。，导致服务不友好，也导致很多人放弃。

DDL执行卡顿传说:用过的同学可能知道，在Galera Cluster中执行一个大表修改操作，会导致整个集群在那里卡顿一段时间，根本不写任何事务。这种情况真的很严重，导致完全在线无法使用。原因是并发控制，因为提交操作设置为串行，DDL执行是提交过程，所以表修改的串行执行。当然，只要执行了，其他事务就可以继续操作，直到执行表修改。这个问题现在还不能解决，但是经过长期使用，我们发现小表可以直接这样操作，甚至更大的都是通过osc来做，很好的避免了这个问题。

谁挡我的道谁就死:因为Galera Cluster在执行DDL时总是有序隔离，所以需要保证每个节点都是同时执行的，当然对于那些Total Order而不是DDL总是有序的，因为每个事务都有相同的GTID值，DDL也不例外。而DDL涉及到表锁和MDL锁。只要执行过程中有MDL锁冲突，DDL在所有情况下都优先，杀死所有使用这个对象的事务。无论是读事务还是写事务，被杀的事务都会报告死锁异常，所以这也是Galera Cluster中关于DDL的一个著名坑。但是，现在真的没有办法解决这个问题，也没有办法避免。不过这个问题的影响是可以接受的，可以先承担。

不朽体:遵循上面的“阻塞我的生命”，如果集群真的被一个DDL卡住，导致整个集群无法移动，所有的写请求都是Hang，那么可能会有人想到一个妙招，说快杀，直接在每个节点上输入kill connection_id，以及其他类似的操作，那么这个时候，我不想看到的信息就被举报了:你不是线程连接的拥有者这个时候， 有的同学可能会哭，但这种情况下，真的没有好的解决办法，或者等DDL执行完成，或者直接杀死数据库，快速重启，快速恢复一个节点提交在线服务。 然后考虑集群中其他节点的数据增量同步。这个坑很大，也是Galera Cluster里最大的坑，需要非常小心，避免出现这样的问题。

4. 适用场景

现在我们对Galera Cluster已经足够了解了，但是在什么情况下才能使用这样一个“完美”的架构呢？或者说，哪个场景不适合使用这样的架构？针对其缺点和优点，可以扬长避短。以下几个方面可以用来理解其适用的场景。

强数据一致性:Galera Cluster可以保证很强的数据一致性，所以更适合要求高数据一致性和完整性的场景，比如事务。正是因为这个特点，Qunar.com将成为Galera Cluster的最大用户。

多点写入:这里要强调的是多点写入的意义，不是支持以多点写入的形式提供服务，更重要的是因为多点写入，DBA在正常维护数据库集群的时候，不会影响业务，也不会真正意识不到，因为只要是主从复制，就不可能有多点写入，导致切换的时候必然会断开旧节点，然后统一切换到新节点。这是无法避免的，但是支持多点写入，切换时允许短时间的多点写入，这样旧的连接不会受到影响，只需要将新的连接路由到新的节点。这个特性对于交易业务来说也是非常理想的。

性能:Galera Cluster可以支持强一致性。毫无疑问，它还以牺牲性能为代价来争取数据一致性。但有必要问一句:“牺牲性能会不会性能太差，这样的架构根本不能满足需求？我在这里只想说，这是一个权衡的过程。QPS有多少服务是盖拉集群无法满足的？我觉得不多。在追求极高性能的时候，也许单个Galera Cluster是不能满足需求的，但毕竟是少数，所以足够了。Galera Cluster一定是MySQL里最好的。

5. 总结

综上所述，Galera Cluster是MySQL数据一致性完全可靠的武器，使用中不用担心数据延迟和数据不一致。DBA已经完全摆脱了复杂的数据修复，解决了复制延迟和维护期间担心影响业务的问题。可以说Galera Cluster是DBA和业务系统的福音，也是MySQL发展的大势所趋。希望它越来越好，希望越来越多的人用它来共同维护这个美好的环境。