PXC介绍

Percona XtraDB Cluster (简称 PXC)集群是基于 Galera 2.x library，事务型应用下的通用的多主同步复制插件，主要用于解决强一致性问题，使得各个节点之间的数据保持实时同步以及实现多节点同时读写。提高了数据库的可靠性，也可以实现读写分离，是 MySQL 关系型数据库中大家公认的集群优选方案之一。

PXC 是一套 MySQL 高可用集群解决方案，与传统的基于主从复制模式的集群架构相比 PXC 最突出特点就是解决了诟病已久的数据复制延迟问题，基本上可以达到实时同步。而且节点与节点之间，他们相互的关系是对等的。PXC 最关注的是数据的一致性，对待事物的行为时，要么在所有节点上执行，要么都不执行，它的实现机制决定了它对待一致性的行为非常严格，这也能非常完美的保证 MySQL 集群的数据一致性。

何谓Galera Cluster？就是集成了Galera插件的MySQL集群，是一种新型的，数据不共享的，高度冗余的高可用方案，目前Galera Cluster有两个版本，分别是Percona Xtradb Cluster及MariaDB Cluster，都是基于Galera的，所以这里都统称为Galera Cluster了，因为Galera本身是具有多主特性的，所以Galera Cluster也就是multi-master的集群架构，如图所示

图中有三个实例，组成了一个集群，而这三个节点与普通的主从架构不同，它们都可以作为主节点，三个节点是对等的，这种一般称为multi-master架构，当有客户端要写入或者读取数据时，随便连接哪个实例都是一样的，读到的数据是相同的，写入某一个节点之后，集群自己会将新数据同步到其它节点上面，这种架构不共享任何数据，是一种高冗余架构。

一般的使用方法是，在这个集群上面，再搭建一个中间层，这个中间层的功能包括建立连接、管理连接池，负责使三个实例的负载基本平衡，负责在客户端与实例的连接断开之后重连，也可以负责读写分离（在机器性能不同的情况下可以做这样的优化）等等，使用这个中间层之后，由于这三个实例的架构在客户端方面是透明的，客户端只需要指定这个集群的数据源地址，连接到中间层即可，中间层会负责客户端与服务器实例连接的传递工作，由于这个架构支持多点写入，所以完全避免了主从复制经常出现的数据不一致的问题，从而可以做到主从读写切换的高度优雅，在不影响用户的情况下，离线维护等工作，MySQL的高可用，从此开始，非常完美。

PXC 的优缺点

优点

服务高可用
数据同步复制(并发复制)，几乎无延迟
多个可同时读写节点，可实现写扩展，不过最好事先进行分库分表，让各个节点分别写不同的表或者库，避免让 galera 解决数据冲突
新节点可以自动部署，部署操作简单
数据严格一致性，尤其适合电商类应用
完全兼容 MySQL

缺点

复制只支持 InnoDB 引擎，其他存储引擎的更改不复制
写入效率取决于节点中最弱的一台，因为 PXC 集群采用的是强一致性原则，一个更改操作在所有节点都成功才算执行成功
所有表都要有主键
不支持 LOCK TABLE 等显式锁操作
锁冲突、死锁问题相对更多
PXC 集群节点越多，数据同步的速度就越慢

适用场景

数据强一致性

因为Galera Cluster，可以保证数据强一致性的，所以它更适合应用于对数据一致性和完整性要求特别高的场景，比如交易

多点写入

这里要强调多点写入的意思，不是要支持以多点写入的方式提供服务，更重要的是，因为有了多点写入，才会使得在DBA正常维护数据库集群的时候，才会不影响到业务，做到真正的无感知，因为只要是主从复制，就不能出现多点写入，从而导致了在切换时，必然要将老节点的连接断掉，然后齐刷刷的切到新节点，这是没办法避免的，而支持了多点写入，在切换时刻允许有短暂的多点写入，从而不会影响老的连接，只需要将新连接都路由到新节点即可。这个特性，对于交易型的业务而言，也是非常渴求的

性能

Galera Cluster，能支持到强一致性，毫无疑问，也是以牺牲性能为代价，争取了数据一致性，但要问：”性能牺牲了，会不会导致性能太差，这样的架构根本不能满足需求呢？”这里只想说的是，这是一个权衡过程，有多少业务，QPS大到Galera Cluster不能满足的？我想是不多的（当然也是有的，可以自行做一些测试），在追求非常高的极致性能情况下，也许单个的Galera Cluster集群是不能满足需求的，但毕竟是少数了，所以够用就好，Galera Cluster必然是MySQL方案中的佼佼者

PXC 与 Replication 的区别

Replication	PXC
数据同步是单向的，master 负责写，然后异步复制给slave；如果 slave 写入数据，不会复制给 master	数据同步时双向的，任何一个 mysql 节点写入数据，都会同步到集群中其它的节点
异步复制，从和主无法保证数据的一致性	同步复制，事务在所有集群节点要么同时提交，要么同时不提交

PXC 的原理

完全兼容 MySQL
同步复制，事务要么在所有节点提交或不提交
多主复制，可以在任意节点进行写操作
在从服务器上并行应用事件，真正意义上的并行复制
节点自动配置，数据一致性，不再是异步复制
故障切换：因为支持多点写入，所以在出现数据库故障时可以很容易的进行故障切换
自动节点克隆：在新增节点或停机维护时，增量数据或基础数据不需要人工手动备份提供，galera cluster 会自动拉取在线节点数据，集群最终会变为一致

本地执行

这个阶段，是事务执行的最初阶段，可以说，这个阶段的执行过程，与单点MySQL执行没什么区别，并发控制当然就是数据库的并发控制了，而不是Galera Cluster的并发控制了

写集发送

在执行完之后，就到了提交阶段，提交之前首先将产生的写集广播出去，而为了保证全局数据的一致性，在写集发送时，需要串行，这个就属于Galera Cluster并发控制的一部分了

写集验证

这个阶段，就是我们通常说的Galera Cluster的验证了，验证是将当前的事务，与本地写集验证缓存集来做验证，通过比对写集中被影响的数据库KEYS，来发现有没有相同的，来确定是不是可以验证通过，那么这个过程，也是串行的

写集提交

这个阶段，是一个事务执行时的最后一个阶段了，验证完成之后，就可以进入提交阶段了，因为些时已经执行完了的，而提交操作的并发控制，是可以通过参数来控制其行为的，即参数repl.commit_order ，默认值为 3，表示提交就是串行的了，推荐使用默认配置，因为这样的结果是，集群中不同节点产生的Binlog是完全一样的，运维中带来了不少好处和方便

写集APPLY

这个阶段，与上面的几个在流程上不太一样，这个阶段是从节点做的事情，从节点只包括两个阶段，即写集验证和写集APPLY，写集APPLY的并发控制，是与参数wsrep_slave_threads有关系的，本身在验证之后，确定了相互的依赖关系之后，如果确定没有关系的，就可以并行了，而并行度，就是参数wsrep_slave_threads的事情了wsrep_slave_threads可以参照参数wsrep_cert_deps_distance来设置

PXC 常用端口

3306：数据库对外服务的端口号。
4444：请求 SST 的端口。全量数据镜象传输端口，全量镜像可以使用 xtrabackup , rsync,mysqldump 等工具，可以使用wsrep_sst_method 变量配置。只会在新节点加入进来时起作用
4567：组成员之间进行沟通的一个端口号。节点之间同步数据时相互通信时使用。
4568：用于传输 IST。相对于SST来说的一个增量。4568端口 IST 只是在节点下线，重启加入那一个时间有用

SST(State Snapshot Transfer): 全量传输

IST(Incremental state Transfer): 增量传输

MySQL 衍生版选择

PXC集群搭建

PXC集群官方推荐使用3个节点搭建一个集群

在线安装PXC节点

Percona XtraDB Cluster 8.0 on CentOS 7

sql复制代码sudo yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm

sudo percona-release enable-only pxc-80 release

sudo percona-release enable tools release

sudo yum install percona-xtradb-cluster

www.percona.com/doc/percona…

手动安装pxc节点

开放防火墙端口，PXC 集群使用的四个端口

csharp复制代码firewall-cmd --zone=public ȁƕadd-port=3306/tcp ȁƕpermanent

firewall-cmd --zone=public ȁƕadd-port=4444/tcp ȁƕpermanent

firewall-cmd --zone=public ȁƕadd-port=4567/tcp ȁƕpermanent

firewall-cmd --zone=public ȁƕadd-port=4568/tcp ȁƕpermanent

firewall-cmd --reload

或者直接关闭防火墙也可以

bash复制代码# 临时关闭防火墙

systemctl stop firewalld.service

# 永久关闭防火墙

systemctl disable firewalld.service

关闭 SELINUX

vim /etc/selinux/config

把 SELINUX 属性值设置成 disabled，之后保存

重启

reboot

下载 PXC 安装包

安装 PXC 里面集成了 Percona Server 数据库，所以不需要安装 Percona Server 数据库

下载完毕后解压缩，在安装软件包之前还需要下载qpress-11-1.el7.x86_64.rpm包

执行下面命令进行安装

yum localinstall *.rpm

配置PXC节点

修改配置

vim /etc/my.cnf

ini复制代码# PXC集群的所有ip

wsrep_cluster_address=gcomm:ȁi192.168.68.140,192.168.68.141,192.168.68.142

# 节点IP地址

wsrep_node_address=192.168.68.140

# 集群名称，集群中保持统一

wsrep_cluster_name=pxc-cluster

# 节点名称，不同的节点名称不同

wsrep_node_name=pxc-cluster-node-1

复制证书文件

在Percona XtraDB Cluster 8.0中，默认情况下启用数据加密复制（通过pxc-encrypt-cluster-traffic 变量控制）。如果不做任何处理，直接启动节点的话，是无法启动成功的。可以有两种解决方案

关闭加密复制

在my.cnf 文件中增加如下配置

1
2
3

ini复制代码#关闭加密传输

pxc-encrypt-cluster-traffic=OFF

也可以启用数据加密复制，如果在启动群集之前禁用了它，则必须停止群集。然后设置加密，并再次启动。设置数据加密复制。群集的每个节点必须使用相同的SSL证书

同步证书

证书以主节点为准，将主节点上的证书即所有 .pem 文件复制到非主节点上

启动节点

主节点的启动

选择其中一个任意一个节点作为主节点使用如下命令启动主节点

systemctl start mysql@bootstrap.service

主节点的管理命令（第一个启动的 PXC 节点）

sql复制代码systemctl start mysql@bootstrap.service

systemctl stop mysql@bootstrap.service

systemctl restart mysql@bootstrap.service

启动非主节点

非主节点的启动就正常了，使用如下命令管理

arduino复制代码systemctl start mysql.service

systemctl stop mysql.service

systemctl status mysql.service

关闭mysql自动启动

由于pxc集群的启动是有先后顺序的，还有就是同步数据的过程中防止同步的数据量过大，所以需要手动关闭和启动mysql节点。以下命令可以关闭服务的自动启动

chkconfig mysql off

集群测试

修改root密码

从日志文件中找到mysql生成的默认密码，然后登陆到mysql中

cat /var/log/mysqld.log |grep password

修改 mysql@localhost 的密码

alter user 'root'@'localhost' identified by 'root';

由于集群已经启动成功，所有的集群节点内容是强一致性的，只要在其中一个节点中更新了密码，其他节点中都会同步

本文转载自: 掘金

开发者博客 – 和开发相关的这里全都有