PXC / Galera Cluster集群概述及原理分析

24123r2

mariadb的galera cluster集群抄袭percona的PXC数据库集群，所以原理一样

### Galera Cluster/ PXC 集群工作原理
client端向server端发送dml更新操作请求时，server的native本地进程处理请求，并返回OK准备接收，client发送commit更新事务给server，server将replicate writeset复制写数据集发给group（cluster集群），cluster将该数据集对应产生的唯一的GTID（global transaction ID）发送给集群每个server（节点）。当前server节点验证通过后，执行commit_cd动作更新本地数据库，并返回OK；若其他节点验证不通过，则执行rollback_cd，回滚刚提交的事务。其他server(other server)接收并验证通过后，执行apply_cd和commit_cd动作更新本地数据库；若验证不通过，则丢弃该数据集。


任意节点收到sql请求，对于dml更新操作事务，在commit之前，由wsrep API调用galera库进行集群内部广播，验证当前事务是否能在所有节点中执行，验证通过后该事务真正提交到集群所有节点执行，反之roll back回滚。此验证机制则是为了保证所有节点的数据一致性。

innodb内部使用悲观锁，保证事务的成功提交和执行。

pxc/galera集群采用乐观锁，所有的事务都广播给集群每个节点，验证不通过再回滚

### PXC/Galera Cluster集群架构

group communication层：主要实现统一全局数据同步策略和集群内部所有事务的排序，便于生成GTID

replication层：主要用于完成数据同步，由applier和slave queue组成。replication模块的效率直接影响整个集群的写入功能

### 主要名词解释

WS    write set写数据集，写/更新事务

IST   Incremental State Transfer增量同步

SST   State Snapshot Transfer增量同步。传输SST的几种方法：mysqldump/xtrabackup/rsync

UUID    节点状态改变及顺序的唯一标识

GTID    Global Transaction ID，由UUID和sequence number偏移量组成。wsrep api中定义的集群内部全局事务id，用于记录集群中发生状态改变的唯一标识以及队列中的偏移量。

wsrep API    在DBMS库和wsrep provider之间提供接口

commit       把事务所做的修改提交到数据库，即在库中执行用户的sql请求

### PXC/Galera Cluster集群端口
3306    数据库对外提供服务的端口

4444    镜像数据传输SST，集群数据同步端口，全量同步，新节点加入时起作用
4567    集群节点间相互通信的端口

4568    增量数据同步IST，节点下线、重启后使用该端口，增量同步数据。


### 节点状态

• OPEN    节点启动成功，尝试连接到集群，如果失败则根据配置退出或创建新的集群
  
• PRIMARY 节点已处于集群中，在新节点加入时，选取donor进行数据同步时会产生的状态
  
• JOINER  节点处于等待接收/接收同步文件时的状态
  
• JOINED   节点完成数据同步，但有部分数据没跟上，在尝试保持和集群进度一致的过程状态
  
  

         例如某个节点故障后，重新加入集群，在追赶集群进度时的状态
5. SYNCED    节点正常提供服务的状态，表示已经同步完成并和集群进度保持一致。
6. DONOR     节点处于为新节点提供全量数据数据同步时的状态。此时该节点对客户端不提供服务。

##节点状态发生变化因素

• 新节点加入集群
  
  
• 节点故障恢复，重新加入集群
  
• 节点同步失效
  
  

### PXC/Galera Cluster集群优缺点

优点：

    1.高可用性。集群多个节点功能平等，提供负载和冗余，避免单点故障

    2.强一致性。集群所有节点同步修改数据，真正同步读写，不存延迟。

    3.易扩展。增加新节点，只需扔进集群，会自动完成SST全量同步，和后续IST增量同步

缺点：

    1.任何更新事务都需要全局验证通过，才会在每个节点库执行。集群性能受限于性能最差的节点

    2.galera/pxc集群保证数据一致性，必须所有节点验证通过。多点并发写入，锁冲突严重。

        例如：多台同时有写操作，每个更新操作时，都会锁库来验证

    3.新节点或延后较大的节点重新加入时，会进行全量拷贝数据SST，作为donor（提供同步文件的节点）的节点在同步过程中无法提供读写，显示状态为donor。完成后的状态为syncd

###当galera cluster集群单个节点或所有节点停机情况分析

• 单个节点停机
  节点停机重启，重新加入集群，通过IST增量同步数据，来保持集群数据的一致性。IST的实现由wsrep_provider_options="gcache.size=1G"参数决定，一般设置为1G。参数大小由什么决定，根据停机时间，若停机一小时，需要确认一小时产生多大的binlog来算出参数大小。
  
  

1.1 停机时间过长，部分数据gcache没有，此时该节点SST全量同步数据。
2. 所有节点关闭，应采用轮巡滚动关闭的方式：a节点关闭修复，加回集群；b节点关闭修复，加回集群...
    原则就是保持cluster中最少一个成员存活，进行滚动重启。

2.1 集群所有节点都关闭了，没有存活的节点的情况
    每个节点数据库关闭后，都会保存最后一个GTID，启动集群时要先启动最后一个关闭的节点，启动顺序和关闭顺序相反。

3. 避免关闭和启动节点时数据丢失
    3.1 原则保持cluster集群中最少有一个成员存货，然后进行滚动重启

    3.2 利用主从的概念，把一个从节点转化为PXC/Galera集群中的节点


### 常见问题汇总

• 如果主节点（负责写入的节点）写入过大，apply_cd时间过长，导致数据更新操作时间过长，怎么处理?
  Wrep_slave_threads参数配置成cpu的个数或者1.5倍。
  
• 脑裂
  任何命令执行出现unknown command，表示出现脑裂，集群中任意两个节点间通信的4567端口不通，并且无法对外提供服务。SET GLOBAL wsrep_provider_options="pc.ignore_sb=true";
  
• 并发写
  如果在集群多个节点进行写/更新操作，有可能同时不同节点update同一行操作时就会出现锁死问题，出现:Error：1213 SQLSTATE:4001.解决：指定更新和写入都在都一个节点操作。
  
• DDL全局锁
  采用pt-online-schema-change
  
• 只支持innodb引擎，表结构必须要有主键，不然会造成集中每个节点的data page里的数据不一致。
  不支持表级锁，即不能lock/unlock tables，使用行级锁
• 新节点加入加入&故障节点恢复加入集群，此时不能有写操作，不然会导致被写入的那台库DDL死锁。所以需要暂停集群业务写操作，等数据一致后在开启写操作。