目录1、xenon基础介绍1.1. xenon是什么1.2. xenon的架构1.3. Xenon的工作原理2、全局事务标识符(GTID)2.1. 什么是GTID2.2. GTID的工作原理3、Mysql主从复制的三种类型3.1. 异步复制3.2. 全同步复制3.3. 半同步复制4、xenon部署环境介绍4.1. 系统环境说明4.2. 服务器规划4.3. 配置主机host4.4. 配置SSH互信4.5. 配置mysql用户sudo权限5、xenon以及相关软件安装5.1. 安装mysql(二进制)5.2. 安装xtrabackup5.3. 安装xenon6、xenon配置过程详解6.1. 配置xenon6.2. 对xenon进行授权7、启动xenon集群与状态监控8、xenon集群日常维护8.1. 监控集群状态8.2. 添加/删除节点8.3. Rebuild 重建节点8.4. 备份 MySQL到本地8.5. 关闭集群9、xenon集群故障切换实践9.1. 手动 Failover/switchover9.2. slave节点故障切换过程9.3. master节点故障切换过程1、xenon基础介绍1.1. xenon是什么Xenon是一款由青云开发团队开源的新一代 MySQL集群高可用工具。基于 Raft协议进行无中心化选主实现主从秒级切换基于Semi-Sync机制保障数据不丢失实现数据强一致性。并结合MySQL5.7及以上版本并行复制特性实现Binlog并行回放大大降低从库延迟。xenon的github地址为https://github.com/radondb/xenon1.2. xenon的架构Xenon的特点(1)、Xenon基于Raft协议进行无中心化选主并能实现秒级切换。(2)、数据一致性依赖于无损半同步Semi-Sync。(3)、借助于配置项leader-start-command和leader-stop-command调用脚本完成故障切换同时通过调用Xtrabackup可实现数据备份和恢复。(4)、支持MySQL5.6、5.7、8.0内核版本。1.3. Xenon的工作原理Xenon是基于RaftSemi-SyncGTID实现的高可用, 保证大多数节点接收到数据。而Raft基于心跳管理, 如果从节点超时收不到主的心跳, 会尝试发起选举, 若得到超过半数非 IDLE 节点的选票, 则会当选为主节点。下面以三节点 (一主两从) Xenon集群来简单说明工作原理。{Leader, [GTID:{1,2,3,4,5}]} {Follower1, [GTID:{1,2,3,4,5}]} {Follower2, [GTID:{1,2,3}]}当 Leader 不可用时, Follower1 和 Follower2 立即参与竞选成为主节点。Xenon校验GTID值较高的Follower 成为新主节点, 上例中GTID值较高的是Follower1 。当GTID值最高的Follower被选举成为新主时, 将结束竞选。示例中Follower1成为新主节点后, 将会拒绝 Follower2 的选举。接着, 自动完成主从切换。2、全局事务标识符(GTID)2.1. 什么是GTIDGTID(Global Transaction ID)是对于一个已提交事务的编号并且是一个全局唯一的编号。GTID实际上是由UUIDTID组成的。其中UUID是一个MySQL实例的唯一标识保存在mysql数据目录下的auto.cnf文件里。TID代表了该实例上已经提交的事务数量并且随着事务提交单调递增。GTID的复制方式是从MySQL5.6.5开始的。通过GTID保证了每个在主库上提交的事务在集群中有一个唯一的ID。这种方式强化了数据库的主备一致性故障恢复以及容错能力。相比传统的复制GTID复制对于运维更加友好根据GTID可以知道事务最初是在哪个实例上提交的产生多少事物等都可以非常直接的标识出来。2.2. GTID的工作原理大致分为如下几个步骤:master更新数据时会在事务前产生GTID一同记录到binlog日志中。slave端的i/o线程将变更的binlog写入到本地的relaylog中。sql线程从relay log中获取GTID然后对比slave端的binlog是否有记录。如果有记录说明该GTID的事务已经执行slave会忽略。中执行该GTID的事务并记录到binlog。·如果没有记录slave就会从relaylog3、Mysql主从复制的三种类型3.1. 异步复制在mysql异步复制的情况下Master Server将自己的binlog通过复制线程传输出去以后MysqlMaster Sever就自动返回数据给客户端而不管slave上是否接受到了这个二进制日志。那么当master宕机后如果master不能恢复此时只能用slave代替master但slave处于同步落后的状态就会导致数据丢失。优点复制的性能最好缺点master挂掉后slave可能会丢失事务3.2. 全同步复制操作完数据库之后binlog的线程会发送请求到备份节点日志必须等待备份节点执行完成之后主节点才能执行后续的操作优点数据不会丢失缺点性能低、非常依赖网络3.3. 半同步复制半同步复制又分为两种分别是传统半同步复制和无损半同步复制。传统半同步复制在传统半同步复制的架构下master将自己的binlog写入到bin-log文件并且sync且向存储引擎提交事务然后一直等待ACK。当至少一个slave接收到binlog后写入relay-log并返回ACK确认信息。master在接收到从库任意一个ACK确认信息后就将结果返回给客户端。优点会有数据丢失风险但很低。缺点会阻塞master session性能稍差非常依赖网络。特点由于master是在三段提交的最后commit阶段完成后才等待所以master的其他session是可以看到这个提交事务的所以这时候master上的数据和slave不一致master crash后slave有数据丢失。无损半同步复制(常用master自己的binlog写入到binlog文件并且sync之后会进入等待ACK当至少一个slave接收到binlog之后写入relay-log并返回ACK确认信息。master接收到从库ACK确认信息之后向存储引擎提交事务最终返回给客户端。优点数据零丢失性能好缺点会阻塞master session非常依赖网络重点由于master是在三段提交的第二阶段sync binlog完成后才等待所以master的其他session是看不见这个提交事务的所以这时候master上的数据和slave一致master crash后slave没有丢失数据。要开启无损半同步复制需要设置如下几个参数:plugin_load rpl_semi_sync_mastersemisync_master.so;rpl_semi_sync_slavesemisync_slave.so loose_rpl_semi_sync_master_enabled 1 loose_rpl_semi_sync_slave_enabled 1 loose_rpl_semi_sync_master_timeout 5000参数rpl_semi_sync_master_wait_point在MySQL的半同步复制中控制master在哪阶段等待来自slave的ACK确认。在MySQL5.7中该参数主要有两个值after_commit和after_sync。after_commit: 这其实就是传统的半同步复制master将自己的binlog写入到bin-log文件并且sync并向存储引擎提交事务然后一直等待ACK。当至少一个slave接收到binlog后写入relay-log并返回ACK确认信息。master在接收到从库任意一个ACK确认信息后就将结果返回给客户端。after_sync: 这其实就是后面马上要讲到的无损半同步复制master将自己的binlog写入到binlog 文件并且sync之后会进入等待ACK当至少一个slave接收到binlog之后写入relay-log并返回ACK确认信息。master接收到从库ACK确认信息之后向存储引擎提交事务最终返回给客户端。4、xenon部署环境介绍4.1. 系统环境说明操作系统: RHEL8.3mysql版本: 二进制安装mysql-5.7.35xtrabackup: version 2.4.244.2. 服务器规划服务器相关IP规划如下:IP地址端口号主机名角色172.16.213.2333306xenon1node节点172.16.213.2343306xenon2node节点172.16.213.2353306xenon3node节点172.16.213.237无无vip注意,这里的vip地址是跟随xenon集群启动的默认vip会绑定在xenon选举出来的master节点上程序要连接mysql的话连接的就是这个vip地址。4.3. 配置主机host注意需要在三个mysql节点都执行如下操作修改系统的/etc/hosts文件添加如下内容127.0.0.1 localhost 172.16.213.233 xenon1 172.16.213.234 xenon2 172.16.213.235 xenon34.4. 配置SSH互信[mysqlxenon1 ~]# ssh-keygen [mysqlxenon1 ~]# ssh-copy-id xenon2 [mysqlxenon1 ~]# ssh-copy-id xenon3然后在xenon2节点执行如下操作[mysqlxenon2 ~]# ssh-keygen [mysqlxenon2 ~]# ssh-copy-id xenon1 [mysqlxenon2 ~]# ssh-copy-id xenon3最后在xenon3节点执行如下操作[mysqlxenon3 ~]# ssh-keygen [mysqlxenon3 ~]# ssh-copy-id xenon1 [mysqlxenon3 ~]# ssh-copy-id xenon24.5. 配置mysql用户sudo权限由于xenon在执行master、slave故障切换的时候需要将vip地址也切换过去而xenon是运行在mysql用户下的所以需要给mysql用户做一个授权让这个普通用户能够执行ip这个linux命令。注意下面的操作需要在三台mysql主机上都执行一遍。这里以xenon1为例修改/etc/sudoers文件添加如下内容[rootxenon1 ~]# vi /etc/sudoers mysql ALL(ALL) NOPASSWD: /usr/sbin/ip设置完成验证下设置是否生效执行如下操作[rootxenon1 ~]# su - mysql -c sudo ip a如果有本机ip地址信息输出表示配置正确。5、xenon以及相关软件安装5.1. 安装mysql(二进制)不赘述前文有提及二进制的mysql必须安装到/usr/local目录下解压即可完成安装安装完成后还需要做一些配置工作首先是添加mysql配置文件这里将mysql配置文件放到/usr/local/mysql/etc/my.cnf路径下配置文件内容如下[rootxenon1 ~]# vim /usr/local/mysql/etc/my.cnf [mysqld] datadir/usr/local/mysql/data socket/tmp/mysql.sock log-error/usr/local/mysql/logs/mysqld.log pid-file/usr/local/mysql/logs/mysqld.pid log_binmysql-bin server-id11 expire_logs_days 10 binlog_format row plugin-loadsemisync_master.so;semisync_slave.so master_info_repository TABLE relay_log_info_repository TABLE relay_log_recovery 1 loose_rpl_semi_sync_master_enabled 1 loose_rpl_semi_sync_slave_enabled 1 loose_rpl_semi_sync_master_timeout 3000 skip-slave-start gtid-mode ON enforce-gtid-consistency ON slave_parallel_type LOGICAL_CLOCK slave_parallel_workers4 slave_preserve_commit_order 1 log-slave-updates5.2. 安装xtrabackupxtrabackup是mysql的一个热备份、恢复工具xenon集成了xtrabackup可以实现集群的备份和迁移安装xtrabackup方法有很多可以下载rpm包直接安装也可以下载Percona提供的yum源进行安装这里通过Percona提供的yum源进行安装首先从https://www.percona.com/downloads/percona-release/ 下载Percona源然后放到服务器上进行安装即可。注意xtrabackup也需要在三个集群节点进行安装。这里以xenon1为例其它节点安装方法相同安装过程如下[rootxenon1 ~]# rpm -ivh percona-release-1.0-27.noarch.rpm有了这个yum源后接下来就可以安装xtrabackup了xtrabackup目前有两个大版本分别是percona-xtrabackup-24和percona-xtrabackup-80其中percona-xtrabackup-80版本主要是针对mysql5.7版本进行备份而percona-xtrabackup-80主要是针对mysql8.0以后的版本进行备份和恢复。这里我下载的是percona-xtrabackup-24安装如下:[rootxenon1 ~]# yum install -y percona-xtrabackup-24安装完成后执行如下命令可以查看版本信息[rootxenon1 ~]# xtrabackup --version xtrabackup: recognized server arguments: --datadir/usr/local/mysql/data --server-id11 --log_bin/usr/local/mysql/data/mysql-bin.log xtrabackup version 2.4.24 based on MySQL server 5.7.35 Linux (x86_64) (revision id: b4ee263)至此xtrabackup安装完成5.3. 安装xenon注意mysql集群三个节点都需要安装编译xenon。这里以xenon1为例首先安装环境依赖主要是安装golang环境操作如下dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm # 安装 git dnf install -y git # 安装 golang编译Xenon必须 dnf install -y golang然后从https://github.com/radondb/xenon/releases/ 选择需要的版本下载xenon源码包。接着就可以编译xenon了过程如下[rootxenon1 ~]# mv xenon /usr/local/ [rootxenon1 ~]# cd /usr/local/xenon [rootxenon1 ~]# make build [rootxenon1 ~]# cd conf/ [rootxenon1 ~]# cp xenon-simple.conf.json xenon.json ---------------修改编译版本上述是老版本--------- cd /usr/local/xenon cp makefile makefile.bak sed -i s/git rev-parse/echo/g makefile sed -i s/git log/echo/g makefile export GO111MODULEoff export GOPATH$(pwd) make build ls -lh bin/这里将xenon安装到了/usr/local目录下其中xenon.json就是xenon的配置文件。记得在xenon2、xenon3节点也执行相同的操作步骤。6、xenon配置过程详解6.1. 配置xenon将xenon在三个节点安装完成后接下来就需要配置xenon了三个集群节点都需要配置xenon这里以xenon1节点为例配置好的xenon.json文件内容如下[rootxenon1 ~]# more /etc/xenon/xenon.json { server: { endpoint:172.16.213.233:8801 }, raft: { meta-datadir:raft.meta, heartbeat-timeout:1000, election-timeout:3000, leader-start-command:sudo /usr/sbin/ip a a 172.16.213.237/24 dev enp0s3 arping -c 3 -A 172.16.213.237 -I enp0s3, leader-stop-command:sudo /usr/sbin/ip a d 172.16.213.237/24 dev enp0s3 }, mysql: #三个服务器默认一样即可 { admin:root, passwd:abc123456, host:127.0.0.1, port:3306, basedir:/usr/local/mysql, defaults-file:/usr/local/mysql/etc/my.cnf, ping-timeout:1000, master-sysvars:super_read_only0;read_only0;sync_binlogdefault;innodb_flush_log_at_trx_commitdefault;rpl_semi_sync_slave_enabled0;rpl_semi_sync_master_enabled1, slave-sysvars: super_read_only1;read_only1;sync_binlog1000;innodb_flush_log_at_trx_commit2;rpl_semi_sync_slave_enabled1;rpl_semi_sync_master_enabled0 }, replication: #主从复制直接写就行 { user:repl, passwd:123456 }, backup: { ssh-host:172.16.213.233, #本地ip地址 ssh-user:mysql, ssh-passwd:mysql123,#本机mysql用户 ssh-port:22, backupdir:/usr/local/mysql/data, #备份的默认路径 xtrabackup-bindir:/usr/bin, backup-iops-limits:100000, backup-use-memory: 2GB, backup-parallel: 2 }, rpc: { request-timeout:500 }, log: { level:INFO } }下面解释下这个配置文件中几个重要选项的含义。server段中endpoint是指定每个节点的ip和启动xenon服务对应的端口8801端口保持默认即可。IP就是三个节点的物理IP地址需要做修改。raft段中leader-start-command选项是配置集群选举后master节点绑定VIP地址的命令。根据前面的规划我们使用的vip地址为172.16.213.237注意IP的写法。leader-stop-command选项是删除VIP地址的命令。mysql段中admin是指定mysql用户一般是rootpasswd是root用户的密码这个密码在上面初始化mysql的时候做个设置host保持默认的127.0.0.1即可port默认是3306basedir指定mysql库的程序根目录我们这个环境是/usr/local/mysqldefaults-file是指定mysql库的配置文件路径我们这里是/usr/local/mysql/etc/my.cnf。master-sysvars是设置节点变为master角色时需要添加的mysql参数配置 而slave-sysvars是设置slave节点mysql的参数配置。replication段指定的是主从复制时对应的复制用户和密码这个复制用户无需创建只需要在这里指定即可xenon会自动创建此用户以及设置用户对应的密码。backup段是配置xenon使用xtrabackup进行备份的相关设置ssh-host是本机对应的IP地址不同节点ip不同记得修改ssh-user是本机的linux用户这里是mysqlssh-passwd是mysql这个Linux用户的密码ssh-port是ssh端口默认是22backupdir是指定通过xtrabackup进行备份时备份数据的存放路径xtrabackup在进行备份的时候会首先删除这个路径下的所有数据然后才开始备份。xtrabackup-bindir是指定xtrabackup这个命令所在的路径默认是/usr/bin。在xenon1节点配置完成后在xenon2、xenon3节点也需要做相同的配置记得修改配置文件中对应的ip地址。6.2. 对xenon进行授权先执行如下操作[rootxenon1 conf]# mkdir /etc/xenon/ [rootxenon1 conf]# cp /usr/local/xenon/conf/xenon.json /etc/xenon/ [rootxenon1 conf]# echo /etc/xenon/xenon.json /usr/local/xenon/bin/config.path [rootmaster conf]# mkdir /usr/local/xenon/logs注意在xenon命令路径中需要有一个名为config的文件否则生成集群节点时会报错。然后对/usr/local/xenon和/etc/xenon/目录进行授权允许mysql用户完全访问操作如下[rootxenon1 conf]# chown mysql.mysql -R /usr/local/xenon [rootxenon1 conf]# chown mysql.mysql -R /etc/xenon/至此xenon配置完毕。7、启动xenon集群与状态监控所有配置工作完成后就可以启动xenon集群了。首先在172.16.213.233节点通过mysql用户启动xenon服务执行如下命令[rootxenon1 ~]# su - mysql [mysqlxenon1 ]$ cd /usr/local/xenon/bin [mysqlxenon1 bin]$ ./xenon -c /etc/xenon/xenon.json /usr/local/xenon/logs/xenon.log 21 [mysqlxenon1 bin]$ ./xenoncli cluster add 172.16.213.233:8801,172.16.213.234:8801注意后面所有对集群的管理和维护操作都通过mysql用户来完成。这里用到了“xenoncli cluster add” 命令这是向xenon集群中添加节点的命令后面会多次用到。接着在172.16.213.233节点查看集群状态执行如下命令注意这里用到了xenoncli cluster mysql这个命令此命令用来查看xenon集群中mysql的状态信息。从上面输出可以看到172.16.213.233节点角色为FOLLOWER处于ALIVE状态并且为READONLY只读而IO/SQL_Running列为true/true表示此节点主从复制关系的IO进程和SQL进程都处于正常状态。而172.16.213.234节点所有状态均为UNKNOW这是因为172.16.213.234节点的xenon服务还未启动所以集群还无法识别这个节点的状态既然如此下面就在172.16.213.234节点启动xenon服务操作如下[rootxenon2 ~]# su - mysql [mysqlxenon2 ~]$ cd /usr/local/xenon/bin [mysqlxenon2 bin]$ ./xenon -c /etc/xenon/xenon.json /usr/local/xenon/logs/xenon.log 21 然后在172.16.213.234节点查看集群状态执行如下命令从上面输出可知172.16.213.234节点启动xenon服务后在集群中的状态变为ALIVE并且默认角色是FOLLOWER同时主从复制关系也自动建立起来了主从状态都正常。现在返回172.16.213.233节点再次查看集群状态输出如下从输出可知172.16.213.234节点从原来的UNKNOW角色变成了FOLLOWER角色同时172.16.213.233节点的角色也从之前的FOLLOWER变成了CANDIDATECANDIDATE表示候选状态也就是说xenon集群至少有两个或以上节点加入才能进行选举现在加入了一个无法完成选举所以接下来还需要在172.16.213.234节点将172.16.213.233节点加入集群才能实现master和slave的选举在172.16.213.234节点执行如下命令[mysqlxenon2 bin]$ ./xenoncli cluster add 172.16.213.233:8801,172.16.213.234:8801然后在172.16.213.234节点查看集群状态如下图所示从输出可知在172.16.213.234节点将xenon1和xenon2都加入集群后因为集群已经有了2个节点因此可以实现正常的选举选举的结果是172.16.213.233节点成为LEADER也就是主从复制中的master节点而172.16.213.234节点成为FOLLOWER角色也就是slave节点这样xenon集群选举就完成了。由于我们是三个节点所以还需要将最后一个节点172.16.213.235也加入集群中在xenon3执行如下命令[rootxenon3 ~]# su - mysql [mysqlxenon3 ~]$ cd /usr/local/xenon/bin [mysqlxenon3 bin]$ ./xenon -c /etc/xenon/xenon.json /usr/local/xenon/logs/xenon.log 21 [mysqlxenon3 bin]$ ./xenoncli cluster add 172.16.213.233:8801,172.16.213.234:8801,172.16.213.235:8801由于有新节点加入集群所以还需要在xenon1、xenon2节点将新的节点依次加入集群首先在172.16.213.233节点执行如下命令[mysqlxenon1 bin]$ ./xenoncli cluster add 172.16.213.233:8801,172.16.213.234:8801,172.16.213.235:8801然后在172.16.213.234节点也执行相同的命令[mysqlxenon2 bin]$ ./xenoncli cluster add 172.16.213.233:8801,172.16.213.234:8801,172.16.213.235:8801最后再返回任意一个集群节点执行如下命令查看集群状态输出结果如下从输出可知新增的节点172.16.213.235加入集群成功角色为FOLLOWER处于READONLY只读状态而处于LEADER 角色的节点状态为READWRITE可读可写这刚好就是mysql主从复制的基本运行逻辑。要查看集群状态的详细信息也可以执行如下命令“xenoncli cluster status”命令主要用来查看集群整体状态例如每个节点的角色mysql状态以及目前集群中哪个是LEADER都有清晰的输出要进行集群故障排查此命令会经常用到。至此xenon集群搭建成功。8、xenon集群日常维护8.1. 监控集群状态要查看集群状态经常执行的命令有如下几个[rootxenon1 ~]# su - mysql [mysqlxenon1 ~]$ cd /usr/local/xenon/bin [mysqlxenon1 bin]$ ./xenoncli cluster status #查看集群状态 [mysqlxenon1 bin]$ ./xenoncli cluster mysql #查看集群mysql的状态 [mysqlxenon1 bin]$ ./xenoncli cluster xenon #查看跟xenon相关的角色信息和配置其中“xenoncli cluster status”用来查看集群整体的状态下图是集群某时刻的一个状态截图从上图可以看出此集群中每个节点的角色、mysql运行状态、Monitor引擎是否运行、主从复制状态以及目前集群leader节点是哪个通过此命令集群所有状态一目了然。“xenoncli cluster mysql”命令主要是查看跟mysql有关的运行状态比如每个节点mysql角色、mysql存活状态、每个节点mysql读写权限、mysql的binlog日志回放位置、主从复制状态等信息。而“xenoncli cluster xenon”命令主要查看跟xenon相关的角色信息以及配置信息如下图所示检查集群一致状态可执行如下命令[mysqlxenon1 bin]$ ./xenoncli cluster raft注意上面命令是在/usr/local/xenon/bin目录下执行的如无特殊说明执行xenoncli命令都是在/usr/local/xenon/bin目录下完成的下面的操作都省去了 “cd /usr/local/xenon/bin”这个步骤。检查集群 GTID 状态可执行如下命令[mysqlxenon1 bin]$ ./xenoncli cluster gtid这个命令主要是查看集群的主从事务同步状态下面是一个输出截图这里重点关注Executed_GTID_Set列和Retrieved_GTID_Set列其中Retrieved_GTID_Set表示从库已经接收到主库的事务编号。 Executed_GTID_Set 表示从库自身已经执行的事务编号。uuid为6a2a5597-46a8-11ec-b8a2-08002735d58b的是172.16.213.233上面的mysql实例并且三个节点都有此UUID这说明此节点曾经是master节点主库6a2a5597-46a8-11ec-b8a2-08002735d58b:1-23960表示172.16.213.233这个mysql一共产生了23960个事务并且两个slave节点接收到了主库的23960个事务且都已全部执行。此外还有一个6a2a5597-46a8-11ec-b8a2-08002735d58d:1-8862的GTID这个GTID在三个节点都有事务查看发现GTID中的UUID刚好是172.16.213.235节点因此目前172.16.213.235节点是master节点主库并且其它两个slave节点接收到了主库的8862个事务且都已全部执行。Retrieved_GTID_Set列中第一行6a2a5597-46a8-11ec-b8a2-08002735d58d:523-8862表示172.16.213.233节点从172.16.213.235节点第523个事务开始接收目前接收到了第8862个事务从这里也可以看出172.16.213.233应该是发生过故障并且执行过恢复所以接收主库的事务不是从1开始的。Retrieved_GTID_Set列中第二行6a2a5597-46a8-11ec-b8a2-08002735d58d:1-8862表示172.16.213.234节点从172.16.213.235节点第1个事务开始接收目前接收到了第8862个事务。8.2. 添加/删除节点要添加一个节点到集群可执行如下命令[mysqlxenon1 bin]$ ./xenoncli cluster add 172.16.213.233:8801,172.16.213.234:8801,172.16.213.235:8801,172.16.213.232:8801其中172.16.213.232是新增节点由于所有集群节点都要能够识别新增的节点所以添加新节点的命令要在xenon集群每个节点都执行一遍。要在xenon集群中删除一个节点可以执行如下命令[mysqlxenon1 bin]$ ./xenoncli cluster remove 172.16.213.232:8801要删除某个节点只需要在集群任意节点执行上面命令即可但被删除的节点上无法删除自己节点的信息也就是说172.16.213.232这个节点被删除后在172.16.213.232这个节点执行“xenoncli cluster mysql”这个命令时还是能看到此节点的信息。不过不要紧此节点既然是删除的节点直接关闭集群服务停止mysql服务即可不会对集群产生影响。8.3. Rebuild 重建节点当某个节点发生故障时可以通过 rebuildme重建此节点例如某节点硬件故障硬件恢复后如果之前数据无法恢复此时可以利用之前的备份然后让此节点加入集群最后就可以使用rebuildme命令来将此节点恢复到最新数据状态。在要做重建的节点执行[mysqlxenon1 bin]$ ./xenoncli mysql rebuildmeXenon 重建的过程可分为如下几个阶段禁用 raft将 Xenon 状态设为 LEARNER如 mysql 进程存在则 stop mysql清空 MySQL 数据目录执行 xtrabackup --backup 以 xbstream 方式获取对端数据执行 xtrabackup --prepare应用 redo log启动 mysql执行 stop slave; reset slave all执行 reset master以 xtrabackup_binlog_info 文件中的 GTID 为准设置 gtid_purged启用 raft将 Xenon 状态设为 FOLLOWER 或 IDLE等待 Xenon 自动 change master to 到主节点执行 start slave。在进行节点重建的时候默认情况下xenon会从集群节点中选取一个最新的slave节点进行数据复制和拷贝但我们也可以指定从哪个节点进行数据的复制和拷贝指定节点复制重建当前 MySQL 节点可通过如下方式[mysqlxenon1 bin]$ ./xenoncli mysql rebuildme --from172.16.213.233:8801注意在执行节点重建时此节点的mysql服务、xenon服务需要处于启动状态也就是说重建的节点一定是集群的成员否则无法执行重建因此故障节点在恢复重建之前最好能通过之前的mysql备份将mysql服务启动起来。然后执行重建。8.4. 备份 MySQL到本地xenon集成了备份功能可以通过指定路径将集群数据备份到某节点某路径下操作命令如下所示[mysqlxenon1 bin]$ ./xenoncli mysql backup --to/home/mysql/data8.5. 关闭集群在xenon集群每个节点依次执行如下命令即可关闭集群这里以xenon1节点为例命令如下[mysqlxenon1 bin]$ ./xenoncli mysql stopmonitor [mysqlxenon1 bin]$ ./xenoncli mysql shutdown [mysqlxenon1 bin]$ pkill xenon其中前面两个命令是关闭xenon的监控引擎、停止mysql服务最后一个命令是关闭xenon进程。9、xenon集群故障切换实践9.1. 手动 Failover/switchoverxenon集群支持故障检测、故障自动切换也支持手动触发主从切换。如果想让哪个节点成为master节点就在哪个节点执行如下命令即可[mysqlxenon2 bin]$ ./xenoncli raft trytoleader上面命令执行完成后查看集群状态可以发现xenon2节点目前变为集群的LEADER角色。9.2. slave节点故障切换过程xenon集群中slave节点发生故障分为几种情况slave节点如果网络故障导致主从同步中断这个问题无需处理只需等待网络恢复后slave节点会自动去同步master节点的binlog数据实现主从同步。如果slave节点上mysql库异常关闭那么xenon进程会尝试重新启动如果能够启动mysql那么自动恢复正常如果xenon进程无法实现重启的那么可能是mysql本身有故障需要检查mysql实例修复问题只要mysql能够正常启动此节点就可以正常加入集群中。如果slave节点所在的主机磁盘故障导致mysql数据丢失或者由于redo log损坏导 致数据库无法启动的此种情况就需要重建此节点这种情况也是最难处理的一种。下面针对上面描述的第三种情况进行恢复演练。第一步获取此前的数据备份通过之前的备份数据恢复这个节点上mysql实例的正常运行。记住一定要通过之前对集群的备份数据进行恢复重新初始化数据库是无法进行恢复的。这里假定172.16.213.234节点发生故障此节点目前是FOLLOWER角色也就是slave节点首先关闭此节点的xenon服务和mysql服务实际环境中mysql可能无法启动了然后将之前的备份恢复到此节点的data目录下操作过程如下#关闭此节点的xenon服务和mysql服务 [mysqlxenon2 bin]$ ps -ef|grep xenon.json|grep -v grep|awk {print $2}|xargs kill -9 [mysqlxenon2 bin]$ /etc/init.d/mysqld stop #把之前mysql的data目录备份或者删除确认可删除情况下 [mysqlxenon2 bin]$ cd /usr/local/mysql/ [mysqlxenon2 mysql]$ mv data data.old #将备份数据拷贝到mysql的data目录下其中备份数据路径是/home/mysql/data [mysqlxenon2 mysql]$ cp -r /home/mysql/data . #数据库恢复完成后最后一步启动xenon服务mysql服务会自动启动 [mysqlxenon2 data]$ cd /usr/local/xenon/bin [mysqlxenon2 bin]$ ./xenon -c /etc/xenon/xenon.json /usr/local/xenon/logs/xenon.log 21 上面步骤恢复完成后可能会自动实现master节点数据同步到此节点那么恢复完成。但也可能出现xenon2节点主从复制失败的情况主要是sql进程异常失败原因是多方面的跟使用的备份有很大关系但解决这个问题的方法是一样的此时需要执行第二个步骤。第二步如果出现了主从同步失败那么最快的方法就是在这个节点执行重建也就是在此节点执行”xenoncli mysql rebuildme“命令但前提是此节点xenon服务和mysql服务已经正常启动。执行重建命令如下[mysqlxenon2 data]$ cd /usr/local/xenon/bin [mysqlxenon2 bin]$ ./xenoncli mysql rebuildme执行”xenoncli mysql rebuildme“命令进行重建后若重建成功此节点数据和master节点完全一致。slave节点恢复成功。9.3. master节点故障切换过程从这个提示中可以看出是主从复制的SQL线程报出来的异常在执行事务6a2a5597-46a8-11ec-b8a2-08002735d58d:1时发现无法复制的错误更详细信息可查看performance_schema.replication_applier_status_by_worker表执行select * from performance_schema.replication_applier_status_by_worker\G;语句那下面就看看此表如下图所示从输出可在错误在于“Table gao.k1 doesnt exist”也就是说xenon1从现在的新master的binlog拉取日志要回放gao.k1表的数据但是发现xenon1库中根本没有这个表所以发生了报错。这种主从复制的问题发生的几率是很高的不同的备份可能会出现不同的问题。出现的问题虽多但解决方法只有一个要解决这个问题最简单、直接的方法就是在此节点执行重建过程如下[mysqlxenon1 bin]$ ./xenoncli mysql rebuildme 2021/11/30 10:27:27.374562 [WARNING] prepare.to.rebuildme IMPORTANT: Please check that the backup run completes successfully. At the end of a successful backup run innobackupex prints completed OK!. 2021/11/30 10:27:27.375371 [WARNING] S1--check.raft.leader 2021/11/30 10:27:27.392982 [WARNING] rebuildme.found.best.slave[172.16.213.234:8801].leader[172.16.213.235:8801] 2021/11/30 10:27:27.393014 [WARNING] S2--prepare.rebuild.from[172.16.213.234:8801].... 2021/11/30 10:27:27.403049 [WARNING] S3--check.bestone[172.16.213.234:8801].is.OK.... 2021/11/30 10:27:27.403075 [WARNING] S4--set.learner 2021/11/30 10:27:27.404604 [WARNING] S5--stop.monitor 2021/11/30 10:27:27.405926 [WARNING] S6--kill.mysql 2021/11/30 10:27:27.488928 [WARNING] S7--check.bestone[172.16.213.234:8801].is.OK.... 2021/11/30 10:27:27.504558 [WARNING] S8--clear.datadir[/usr/local/mysql/data] 2021/11/30 10:27:27.541446 [WARNING] S9--xtrabackup.begin.... 2021/11/30 10:27:27.542133 [WARNING] rebuildme.backup.req[{From: BackupDir:/usr/local/mysql/data SSHHost:172.16.213.233 SSHUser:mysql SSHPasswd:mysql123 SSHPort:22 IOPSLimits:100000 XtrabackupBinDir:/usr/bin}].from[172.16.213.234:8801] 2021/11/30 10:27:44.235087 [WARNING] S9--xtrabackup.end.... 2021/11/30 10:27:44.235131 [WARNING] S10--apply-log.begin.... 2021/11/30 10:27:50.200013 [WARNING] S10--apply-log.end.... 2021/11/30 10:27:50.200058 [WARNING] S11--start.mysql.begin... 2021/11/30 10:27:50.201383 [WARNING] S11--start.mysql.end... 2021/11/30 10:27:50.201402 [WARNING] S12--wait.mysqld.running.begin.... 2021/11/30 10:27:53.250253 [WARNING] wait.mysqld.running... 2021/11/30 10:27:53.331268 [WARNING] S12--wait.mysqld.running.end.... 2021/11/30 10:27:53.331286 [WARNING] S13--wait.mysql.working.begin.... 2021/11/30 10:27:56.332544 [WARNING] wait.mysql.working... 2021/11/30 10:27:56.333433 [WARNING] S13--wait.mysql.working.end.... 2021/11/30 10:27:56.333458 [WARNING] S14--stop.and.reset.slave.begin.... 2021/11/30 10:27:56.615532 [WARNING] S14--stop.and.reset.slave.end.... 2021/11/30 10:27:56.615562 [WARNING] S15--reset.master.begin.... 2021/11/30 10:27:56.856596 [WARNING] S15--reset.master.end.... 2021/11/30 10:27:56.856704 [WARNING] S15--set.gtid_purged[6a2a5597-46a8-11ec-b8a2-08002735d58b:1-23960, 6a2a5597-46a8-11ec-b8a2-08002735d58d:1-522 ].begin.... 2021/11/30 10:27:56.898296 [WARNING] S15--set.gtid_purged.end.... 2021/11/30 10:27:56.898326 [WARNING] S16--enable.raft.begin... 2021/11/30 10:27:56.900621 [WARNING] S16--enable.raft.done... 2021/11/30 10:27:56.900646 [WARNING] S17--wait[3000 ms].change.to.master... 2021/11/30 10:27:56.900690 [WARNING] S18--start.slave.begin.... 2021/11/30 10:27:57.274490 [WARNING] S18--start.slave.end.... 2021/11/30 10:27:57.274519 [WARNING] completed OK! 2021/11/30 10:27:57.274529 [WARNING] rebuildme.all.done....从这个输出可知在执行重建过程中xenon自动从集群最新节点172.16.213.234:8801进行数据读取和备份然后将数据复制到xenon1节点上最后重建成功。这个恢复过程其实是利用了之前的数据备份由此可知在xenon集群中一定要定期做数据备份这样在某节点出现问题的时候可以通过备份来进行恢复。