mysql pxc galera_PXC / Galera Cluster集群概述及原理分析
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死锁。所以需要暂停集群业务写操作，等数据一致后在开启写操作。