PXC原理与启动关闭及注意事项

一.PXC原理介绍



从上图可以看出：

当client端执行dml操作时，将操作发给server，server的native进程处理请求，client端执行commit，server将复制写数据集发给group(cluster)，cluster中每个动作对应一个GTID，其它server接收到并通过验证(合并数据)后，执行appyl_cb动作和commit_cb动作，若验证没通过，则会退出处理;当前server节点验证通过后，执行commit_cb，并返回，若没通过，执行rollback_cb。

只要当前节点执行了commit_cb和其它节点验证通过后就可返回。

3306:数据库对外服务的端口号

4444:请求SST，在新节点加入时起作用

4567:组成员之间沟通的端口

4568:传输IST，节点下线，重启加入时起作用

SST:全量同步

IST:增量同步

问题：如果主节点写入过大，apply_cb时间跟不上，怎么处理？ Wsrep_slave_threads参数配置成cpu的个数相等或是1.5倍。

二．启动和关闭

State Snapshot Transfer(SST)，每个节点都有一份独立的数据，当我们用mysql bootstrap-pxc启动第一个节点，在第一个节点上把帐号初始化，其它节点启动后加入进来。

集群中有哪些节点是由wsrep_cluster_address = gcomm://xxxx,,xxxx,xxx

参数决定。

第一个节点把自己备份一下(snapshot)传给加入的新节点，第三个节点的死活是由前两个节点投票决定。



状态机变化阶段：

1.OPEN: 节点启动成功，尝试连接到集群，如果失败则根据配置退出或创建新的集群

2.PRIMARY: 节点处于集群PC中，尝试从集群中选取donor进行数据同步

3.JOINER: 节点处于等待接收/接收数据文件状态，数据传输完成后在本地加载数据

4.JOINED: 节点完成数据同步工作，尝试保持和集群进度一致

5.SYNCED：节点正常提供服务：数据的读写，集群数据的同步，新加入节点的sst请求

6.DONOR(贡献数据者)：节点处于为新节点准备或传输集群全量数据状态，对客户端不可用。

状态机变化因素：

1.新节点加入集群

2.节点故障恢复

3.节点同步失效

传输SST有几种方法:

mysqldump

xtrabackup

rsync

当node3停机重启后，通过IST来同步增量数据，来完成保证与node1和node2的数据一致，IST的实现是由wsrep_provider_options="gcache.size=1G"参数决定，一般设置为1G大，参数大小是由什么决定的，根据停机时间，若停机一小时，需要确认1小时内产生多大的binlog来算出参数大小。

假设我们三个节点都关闭了，会发生什么呢
全部传SST，因为gcache数据没了
全部关闭需要采用滚动关闭方式：
1． 关闭node1，修复完后，启动加回来;
2． 关闭node2,修复完后，启动加回来;
3． ………………….,直到最后一个节点
4． 原则要保持Group里最少一个成员活着

数据库关闭之后，最会保存一个last Txid，所以启动时，先要启动最后一个关闭的节点，启动顺序和关闭顺序刚好相反。
wsrep_recover=on参数在启动时加入，用于从log中分析gtid。
怎样避免关闭和启动时数据丢失？

1. 所有的节点中最少有一个在线，进行滚动重启;

2. 利用主从的概念，把一个从节点转化成PXC里的节点。

三. pxc注意的问题
1. 脑裂
任何命令执行出现unkown command ，表示出现脑裂，集群两节点间4567端口连不通，无法提供对外服务。
SET GLOBAL wsrep_provider_options="pc.ignore_sb=true";
2. 并发写
三个节点的自增起始值为1、2、3，步长都为3，解决了insert问题，但update同时对一行操作就会有问题，出现：Error： 1213 SQLSTATE: 40001，所以更新和写入在一个节点上操作。

3. DDL

引起全局锁，采用：pt-online-schema-change

4. MyISAM引擎不能被复制，只支持innodb

5. pxc结构里面必须有主键

如果没有主建，有可能会造成集中每个节点的Data page里的数据不一样

6. 不支持表级锁

不支持lock /unlock tables

7. pxc里只能把slow log ,query log 放到File里

8. 不支持XA事务

9. 性能由集群中性能最差的节点决定