PXC-mysql集群的部署及灾难恢复测试
自从生产发现mysql双主问题以来，瞬间开始了mysql大型填坑工程……，这次可以算完结篇了。
近期在看openstack的高可用架构，发现各种文档文章都在介绍galera+xtrabackup来实现元数据库的高可用架构，所以搭了个环境来测试实现原理及日常维护操作。
环境：4台虚拟机，Centos7.6，配置随意
概念提要：
galera作为mysql的真-多主集群架构，提供了三种同步方式：mysqldump、rsync和xtrabackup，以下是优缺点
galera的节点状态有以下几种：
Open |
节点启动成功，尝试连接到集群 |
Primary |
节点已处于集群中，在新节点加入时，选取donor进行数据库同步时会产生的状态 |
Joiner |
节点处于等待接收或正在接收同步文件的状态 |
Joined |
节点完成数据同步，但还有部分数据不是最新的，在追赶与集群数据一致的状态 |
Synced |
节点正常提供服务的状态，表示当前节点数据状态与集群数据状态是一致的 |
Donor |
表示该节点被选为Donor节点，正在为新加进来的节点进行全量数据同步，此时该节点对客户端不提供服务 |
使用show status like 'wsrep_local_state_comment'；来查看
同步机制：
IST: Incremental State Transfer 增量同步
SST：State Snapshot Transfer 全量同步
部署开始：
从http://rpm.pbone.net/index.php3下载libev依赖包并安装：
libev-4.15-7.el7.x86_64.rpm
yum install perl-Time-HiRes
yum -y installperl-DBD-MySQL.x86_64
yum -y install libaio*
yum -y install perl
yum -y install rsync
https://releases.galeracluster.com
下载galera和wsrep的rpm包
https://www.percona.com
下载percona-xtrabackup备份插件
rpm -qa | grep -E 'galera|wsrep|percona'
galera-3-25.3.28-1.el7.x86_64
mysql-wsrep-common-5.7-5.7.28-25.20.el7.x86_64
mysql-wsrep-client-5.7-5.7.28-25.20.el7.x86_64
percona-xtrabackup-24-2.4.18-1.el7.x86_64
mysql-wsrep-libs-compat-5.7-5.7.28-25.20.el7.x86_64
mysql-wsrep-libs-5.7-5.7.28-25.20.el7.x86_64
mysql-wsrep-server-5.7-5.7.28-25.20.el7.x86_64
percona-xtrabackup-24-debuginfo-2.4.18-1.el7.x86_64
安装完成后，配置mysql
[root@galera1 opt]# grep ^[0-Z] /etc/my.cnf
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
symbolic-links=0
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
wsrep_provider=/usr/lib64/galera-3/libgalera_smm.so
wsrep_cluster_name=mysql_galera_cluster
wsrep_cluster_address="gcomm://192.168.245.131,192.168.245.132,192.168.245.133"
wsrep_sst_method=xtrabackup
wsrep_sst_auth=root:P@sswo2d
wsrep_node_name=galera1
#节点名称，各个节点需按实际配置
wsrep_node_address=192.168.245.131
#节点ip，各个节点需按实际配置
以galera作为主节点，启动主节点
/usr/bin/mysqld_bootstrap
配置mysql密码
grep -i 'temp' /var/log/mysqld.log
mysqladmin -uroot -ppassword 'P@sswo2d'
随后在galera2、galera3 启动mysqld
systemctl start mysqld
测试数据：
-- galera1
create database test;
use test;
create table t1(a int);
insert into t1 values(1);
-- galera2
use test;
create table t2(a int);
insert into t2 values(2);
-- galera3
use test;
create table t3(a int);
insert into t3 values(3);
galera集群配置安装配置完成！
场景一：
停机维护后启动集群
比较特殊的是，galera需要找到最后一台离开集群的节点作为主节点重新启动：
cat /var/lib/mysql/grastate.dat
[root@galera3 ~]# cat/var/lib/mysql/grastate.dat
# GALERA saved state
version: 2.1
uuid: 19c74031-318a-11ea-b151-923bc3a3d033
seqno: 8
safe_to_bootstrap: 1
发现galera3 是最后离开集群的，galera3 上执行（这种方式启动自带new-cluster）
/usr/bin/mysqld_bootstrap
其他节点启动:systemctl start mysqld
验证：
场景二：
添加新节点
新建虚拟机galera4，安装rpm包后
/etc/my.cnf
wsrep_provider=/usr/lib64/galera-3/libgalera_smm.so
wsrep_cluster_name=mysql_galera_cluster
wsrep_cluster_address="gcomm://192.168.245.131,192.168.245.132,192.168.245.133,192.168.245.134"
wsrep_sst_method=xtrabackup
wsrep_sst_auth=root:P@sswo2d
wsrep_node_name=galera4
wsrep_node_address=192.168.245.134
systemctl start mysqld
启动完成后查看同步效果
验证数据，在galera4上：
场景三：
恢复故障节点
假设galera3 节点服务器硬件损坏宕机，数据不同步
此时只需要删除galera缓存文件后重启mysql服务即可
重启mysqld
场景四：
假设数据文件全部损坏，删除/var/lib/mysql/目录下所有文件
重启后恢复
查看日志，galera3节点从其他节点拉取了数据文件，恢复服务
场景五：
生产环境中，数据过于巨大，由于SST在复制过程中会影响DDL业务，所以采用IST复制来减少影响，计划使用galera3的全量及增量备份来恢复galera4（模拟新加节点）的数据。
Galera3节点操作：
本地全量备份：
innobackupex--defaults-file=/etc/my.cnf --user=root --password=P@sswo2d--socket=/var/lib/mysql/mysql.sock --galera-info --no-lock /root/galera-backup/full/
建个测试库，测试增量备份
mysql> create database backup;
Query OK, 1 row affected (0.01 sec)
本地增量备份：
innobackupex --defaults-file=/etc/my.cnf --user=root--password=P@sswo2d--incremental-basedir=/root/galera-backup/full/2020-01-08_04-30-05--incremental /root/galera-backup/incr/
从galera3 拷贝备份文件到galera4，删除galera4现有的数据文件，模拟该节点新加入集群，需要同步数据：
scp -r /root/galera-backup/ galera4:/root/
在galera4上先恢复全量restore：
innobackupex --defaults-file=/etc/my.cnf--user=root --password=P@sswo2d --apply-log --redo-only /root/galera-backup/full/2020-01-08_04-30-05
回放增量recovery：
innobackupex --defaults-file=/etc/my.cnf--user=root --password=P@sswo2d --apply-log /root/galera-backup/full/2020-01-08_04-30-05 --incremental-dir=/root/galera-backup/incr/2020-01-08_04-31-43/
回放全量recovery：
innobackupex --defaults-file=/etc/my.cnf--user=root --password=P@sswo2d --apply-log /root/galera-backup/full/2020-01-08_04-30-05
生成数据文件cp-back：
innobackupex --defaults-file=/etc/my.cnf --user=root --password=P@sswo2d --copy-back /root/galera-backup/full/2020-01-08_04-30-05
生成grastate.dat文件
根据xtrabackup_galera_info文件中的内容生成grastate.dat文件，用于IST增量同步。查看galera4节点上的xtrabackup_galera_info文件
cat xtrabackup_galera_info
19c74031-318a-11ea-b151-923bc3a3d033:9
从galera3 拷贝grastate.dat并修改seqno：
# GALERA saved state
version: 2.1
uuid: 19c74031-318a-11ea-b151-923bc3a3d033
seqno: 9
safe_to_bootstrap: 0
更改权限
chown -R mysql:mysql /var/lib/mysql/
启动galera4：
systemctl startmysqld
验证数据
场景六：
集群灾难恢复
做个全备和增量备份，这时误操作删库：
恢复
计划使用galera4 作为恢复节点，停库，清数据
先恢复全量restore：
innobackupex --defaults-file=/etc/my.cnf--user=root --password=P@sswo2d --apply-log --redo-only /root/galera-backup/full/2020-01-07_04-15-47
回放增量recovery：
innobackupex --defaults-file=/etc/my.cnf--user=root --password=P@sswo2d --apply-log/root/galera-backup/full/2020-01-07_04-15-47/ --incremental-dir=/root/galera-backup/incr/2020-01-07_04-16-50/
回放全量recovery：
innobackupex --defaults-file=/etc/my.cnf--user=root --password=P@sswo2d --apply-log/root/galera-backup/full/2020-01-07_04-15-47
生成数据文件cp-back：
innobackupex --defaults-file=/etc/my.cnf --user=root --password=P@sswo2d --copy-back /root/galera-backup/full/2020-01-07_04-15-47
修改权限
chown -R mysql:mysql /var/lib/mysql/
停止其他节点mysqld，以主节点启动最新数据节点galera4
galera1、glera2、galera3上执行systemctl stop mysqld
galera4 以新集群主节点方式启动
/usr/bin/mysqld_bootstrap
验证数据恢复成功
其他节点已经加入集群
验证集群数据
全库完整恢复！
经过模拟的六个常见场景的恢复备份操作，架构确实实现了一个多主mysql集群的在线备份和恢复。
总结几个运维经常需要查看的状态和参数：
show status like ‘wsrep_local_state_comment'; 节点状态
show status like ‘wsrep_cluster_status'; 集群状态
show status like ‘wsrep_cluster_size'; 存活节点数量
大型集群中使用该架构作为元数据库的备份策略可以考虑这样：
3个节点，每个节点均配置定时备份策略，备份时间点错开。
每周日00：00点一次全备，每天00：00点进行增量备份，自动清理前一个月的备份文件。