PXC使用与总结
PXC使用与总结
1、PXC是什么
基于Galera协议的Codership提供多主数据同步复制机制，可以实现多个节点间的数据同步复制以及读写，并且可保障数据库的服务高可用及数据一致性。
基于Galera的高可用方案主要有MariaDB Galera Cluster和Percona XtraDB Cluster（简称PXC），目前PXC用的会比较多一些。
MariaDB的集群原理跟PXC一样,MariDB-Cluster其实就是PXC，两者原理是一样的。要搭建PXC架构至少需要3个mysql实例来组成一个集群，三个实例之间不是主从模式，而是各自为主，所以三者是对等关系，不分从属。
2、PXC的特点
多主架构：真正的多点读写集群，在任何时候读写的数据都是最新的。
同步复制：集群不同节点之间的数据同步，没有延迟，在数据库挂掉之后，数据不会丢失。
并发复制：从节点在apply数据时，支持并行执行，有更好的性能表现，真正意义上的并行复制。
故障切换：因为支持多节点写入，所以在出现数据库故障时可以很容易的进行故障切换。
热插拔：在服务期间，如果数据库挂了，只要监控程序发现的够快，不可服务时间就会非常少，在节点故障期间，节点本身对集群的影响非常小。
自动节点克隆：在新增节点或停机维护时，增量数据或基础数据不需要人工手动备份提供，galera cluster会自动拉取在线节点数据，集群最终会变为一致。
对应用透明：集群的维护，对应用程序是透明的，几乎感觉不到。
PXC最大的优势：强一致性、无同步延迟。
3、PXC的优缺点
3.1、PXC的优点
1）实现mysql数据库集群架构的高可用性和数据的强一致性。
2）完成了真正的多节点读写的集群方案。
3）改善了传统意义上的主从复制延迟问题，基本上达到了实时同步。
4）新加入的节点可以自动部署，无须提供手动备份，维护起来很方便。
5）由于是多节点写入，所以数据库故障切换很容易。
6）完全兼容MySQL；
3.2、PXC的缺点
1）新加入的节点开销大，需要复制完整的数据。采用SST传输开销太大。
2）任何更新事务都需要全局验证通过，才会在每个节点库上执行，集群性能受限于性能最差的节点。
3）因为需要保证数据的一致性，所以在多节点并发写时，锁冲突问题比较严重。
4）因为使用乐观锁，所以建议使用小事物。
5）存在写扩大问题，所有的节点上都会发生相同操作。
6）只支持innodb存储引擎的表。
7）没有表级别的锁定，执行DDL语句操作会把整个集群锁住，而且也 kill 不了(建议使用Osc操作，即在线DDL）
8）所有的表必须含有主键，不然操作数据时会报错。
4、PXC的原理
4.1、名词介绍
WS：write set 写集
IST: Incremental State Transfer 增量同步
SST：State Snapshot Transfer 全量同步
pxc中一个事务=一个写集=一个GTID（PXC特有）
GTID由UUID（集群唯一) + seqno（集群唯一）组成
4.2、工作原理
PXC使用的4个端口号
3306：数据库对外服务的端口号
4444：请求SST用的。 SST: 镜象传输方法 xtrabackup , rsync ,mysqldump
4567: 组成员之间进行沟通的一个端口号
4568: 传输IST用的。相对于SST来说的一个增量。
原理：
首先客户端先发起一个事务，该事务先在本地执行，执行完成之后就要发起对事务的提交操作了。在提交之前需要将产生的数据写集广播出去，然后获取到一个全局的事务ID号，一并传送到另外的节点上面。通过合并数据之后，发现没有冲突数据，执行apply_cd和commit_cb动作，如果发现冲突就需要取消此次事务的操作。而当前server节点通过验证之后，执行提交操作，并返回OK，如果验证没通过，则执行回滚。当然在生产中至少要有3个节点的集群环境，如果其中一个节点没有验证通过，出现了数据冲突，那么此时采取的方式就是将出现不一致的节点踢出集群环境，而且它自己会执行shutdown命令，自动关机。
4.3、节点状态变化阶段：
open：节点启动成功，尝试连接到集群。
primary：节点已处于集群中，在新节点加入时，选取donor进行数据同步时会产生的状态。
joiner：节点处于等待接收/接收数据同步文件时的状态。
joined：节点完成数据同步的工作，尝试保持和集群进度一致。
synced：节点正常提供服务的状态，表示已经同步完成并和集群进度保持一致。
doner：节点处于为新加入的节点提供全量数据时的状态。