MySQL PXC 集群运维指南

一、PXC方案概述
二、PXC基础知识
三、PXC节点的配置安装
四、PXC节点的上线与下线
五、其他

一、PXC方案概述

Percona XtraDB Cluster (PXC) 是一个完全开源的 MySQL 数据库集群解决方案，它可确保高可用性，防止停机和数据丢失，并为不断增长的环境提供线性可扩展性。它将 Percona Server 和 Percona XtraBackup 与 Galera 库集成在一起，以实现同步多源复制。

集群由节点组成，其中每个节点包含在节点间同步的相同数据集。推荐的配置是至少有 3 个节点，也可以有 2 个节点，但不建议使用2个节点。每个节点都是一个常规的 MySQL Server 实例。可以将现有的 MySQL Server 实例转换为节点，并使用该节点作为基础运行集群。还可以从集群中分离任何节点并将其用作常规 MySQL 服务器实例。

当执行查询时，它会在节点上本地执行。所有数据都在本地可用，无需远程访问。

没有中央管理。可以在任何时间点解绑任何节点，集群将继续运行而不会丢失任何数据。

PXC是扩展读取工作负载的好解决方案，可横向扩展以实现负荷降低。可以对任何节点进行读取查询。

新近实施的PXC集群版本均为 8.0，Percona XtraDB Cluster 8.0与MySQL Server Community Edition 8.0和Percona Server for MySQL 8.0完全兼容。

如图是3节点的架构，可以看到每个节点都支持读写。

二、PXC基础知识

■ PXC集群使用四个端口

端口描述

3306 MySQL服务端口

4444 请求全量同步（SST）端口

4567 数据库节点之间的通信端口

4568 请求增量同步（IST）端口

因此如系统启用了防火墙则需开放这些端口，或者关闭防火墙

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

■ 关于SST同步

Different from previous version

The variable wsrep_sst_auth has been removed. Percona XtraDB Cluster 8.0 automatically creates the system user mysql.pxc.internal.session. During SST, the user mysql.pxc.sst.user and the role mysql.pxc.sst.role are created on the donor node.

■ 节点状态定义

OPEN: 节点启动成功

PRIMARY: 节点成功加入集群

JOINER: 与其他节点同步数据

JOINED: 与其他节点同步数据成功

SYNCED: 与集群同步完成，可以对外提供服务

DONER: 接收其他节点的全量数据同步，处于不可用

【wsrep_local_state】当前节点状态,值为4表示正常

共有四个值:

joining:节点正在加入集群

doner: 节点处于为新加入节点提供全量数据时的状态

joined: 当前节点已成功加入集群

synced: 当前节点与集群中各节点是同步状态

【wsrep_cluster_status】集群组成的状态，应为"Primary", 否则说明出现脑裂现象

【wsrep_ready】应为为ON，表示当前节点可以正常提供服务；若为OFF, 则该节点可能发生脑裂或网络问题导致

【wsrep_local_state_uuid】集群中所有节点的该状态值应该是相同的，如果有不同值节点，说明其没有加入集群

【wsrep_cluster_state_uuid】与【wsrep_local_state_uuid】值一致

【wsrep_gcomm_uuid】各个节点的值不同

■ 最常使用的查看命令

show variables like 'wsrep%';

show status like 'wsrep%';

三、PXC节点的配置安装

最靠谱的参考文档，一定是官方文档

https://www.percona.com/doc/percona-xtradb-cluster/8.0/index.html

各类网文水平参差不齐，错误百出，仅供参考

四、PXC节点的上线与下线

■ 查看节点的服务状态

systemctl status mysql

systemctl status mysql@bootstrap

根据以上命令可以确认哪个节点是集群启动的首节点

■ PXC节点的安全下线

节点是怎么启动的，就使用对应的命令去关闭

启动【首节点】命令：

systemctl start mysql@bootstrap

对应关闭命令：

systemctl stop mysql@bootstrap

启动【其他节点】命令：

systemctl start mysql

对应关闭命令：

systemctl stop mysql

■ 如集群中还有正常运行的节点，其他节点只需按普通节点上线即可

systemctl start mysql

■ 如所有PXC节点都是安全下线的，则在启动集群时，需先启动最后下线的节点

systemctl start mysql@bootstrap

■ 某节点能否作为首节点启动，可以通过查看 grastate.dat 文件得知

cat /mysql/pxc/data/grastate.dat

safe_to_bootstrap: 0

说明：safe_to_bootstrap 的值为 0 时不能作为首节点启动，为1时可以作为首节点启动

PXC集群中最后一个下线的节点会将 safe_to_bootstrap 的值改为1，下次启动集群时就需将该节点作为首节点启动

最后一个下线的节点数据是最新的，将其作为首节点启动，然后让其他节点与该节点进行数据同步，这样才能保证集群中的数据是最新的，否则可能导致集群中数据是某个时间点之前的旧数据

safe_to_bootstrap 为 1时，必须使用 systemctl start mysql@bootstrap 的方式启动

■ 如PXC节点都是意外退出的，且不是在同一时间退出的

PXC集群中一半以上的节点因意外宕机而无法访问时，PXC集群就会停止运行

但如果这些PXC节点是以安全下线的方式退出，则不会引发集群自动停止运行的问题，只会缩小集群的规模

只有意外下线一半以上节点时集群才会自动停止，意外下线的情况包括：

宕机、挂起、关机、重启、断电、断网等，就是没有使用相应停止命令安全下线都属意外下线

只要PXC集群中的节点不是同时意外退出的，那么当集群还剩一个节点时，该节点就会自动将grastate.dat文件中的 safe_to_bootstrap 值改为1，所以在重启集群时，也是先启动最后一个退出的节点

■ 如PXC节点都是同时意外退出的，则需要修改grastate.dat文件

当集群所有节点正常运行时，safe_to_bootstrap 值都为 0

当集群中所有节点都是在同一时间因意外情况而退出，此时所有节点的 safe_to_bootstrap 都为 0 ，因为没有一个节点来得及去修改 safe_to_bootstrap 的值。当所有节点的 safe_to_bootstrap 均为 0 时，PXC集群是无法启动的。

在这种情况下我们就只能手动选择一个节点，将 safe_to_bootstrap 修改为 1 ，然后将该节点作为首节点进行启动：

vim grastate.dat

safe_to_bootstrap: 1

systemctl start mysql@bootstrap

接着再依次正常启动其他节点：

systemctl start mysql

五、其他

关于ProxySQL与keepalive的配置与运维，此处暂不赘述。