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

不过在运维过程中,有些技术特点还是需要注意的,这样才能做到知此知彼,百战百胜,因为现在MySQL主从结构的集群已经都是被大家所熟知的了,而Galera Cluster是一个新的技术,是一个在不断成熟的技术,所以很多想了解这个技术的同学,能够得到的资料很少,除了官方的手册之外,基本没有一些讲得深入的,用来传道授业解惑的运维资料,这无疑为很多同学设置了不低的门槛,最终有很多人因为一些特性,导致最终放弃了Galera Cluster的选择.

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

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

      

      图2 galera原理图

   3. 图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的从节点再发起一个解除的消息,让整个集群再恢复.

但我们一般所关心的,就是如何解决,下面有几个一般所采用的方法：

1. 发送FC消息的节点,硬件有可能出现问题了,比如IO写不进去,很慢,CPU异常高等
2. 发送FC消息的节点,本身数据库压力太高,比如当前节点承载太多的读,导致机器Load高,IO压力大等等.
3. 发送FC消息的节点,硬件压力都没有太大问题,但做得比较慢,一般原因是主库并发高,但从节点的并发跟不上主库,那么此时可能需要观察这两个节点的并发度大小,可以参考状态参数wsrep_cert_deps_distance的值,来调整从节点的wsrep_slave_threads,此时应该是可以解决或者缓解的,这个问题可以这样去理解,假设集群每个节点的硬件资源都是相当的,那么主库可以执行完,从库为什么做不过来?那么一般思路就是像处理主从复制的延迟问题一样.
4. 检查存不存在没有主键的表,因为Galera的复制是行模式的,所以如果存在这样的表时,主节点是通过语句来修改的,比如一个更新语句,更新了全表,而从节点收到之后,就会针对每一行的Binlog做一次全表扫描,这样导致这个事务在从节点执行,比在主节点执行慢十倍,或者百倍,从而导致从节点堆积进而产生FC.

可以看出,其实这些方法,都是用来解决主从复制延迟的方法,没什么两样,在了解Flow Control的情况下,解决它并不是难事儿.

3.3 有很多坑?

（编辑：ASP站长网）