企业官网建设流程全解析

目录

1、xenon基础介绍

1.1. xenon是什么

1.2. xenon的架构

1.3. Xenon的工作原理

2、全局事务标识符(GTID)

2.1. 什么是GTID

2.2. GTID的工作原理

3、Mysql主从复制的三种类型

3.1. 异步复制

3.2. 全同步复制

3.3. 半同步复制

4、xenon部署环境介绍

4.1. 系统环境说明

4.2. 服务器规划

4.3. 配置主机host

4.4. 配置SSH互信

4.5. 配置mysql用户sudo权限

5、xenon以及相关软件安装

5.1. 安装mysql(二进制)

5.2. 安装xtrabackup

5.3. 安装xenon

6、xenon配置过程详解

6.1. 配置xenon

6.2. 对xenon进行授权

7、启动xenon集群与状态监控

8、xenon集群日常维护

8.1. 监控集群状态

8.2. 添加/删除节点

8.3. Rebuild 重建节点

8.4. 备份 MySQL到本地

8.5. 关闭集群

9、xenon集群故障切换实践

9.1. 手动 Failover/switchover

9.2. slave节点故障切换过程

9.3. master节点故障切换过程

1、xenon基础介绍

1.1. xenon是什么

Xenon是一款由青云开发团队开源的新一代 MySQL集群高可用工具。基于 Raft协议进行无中心化选主，实现主从秒级切换；基于Semi-Sync机制，保障数据不丢失，实现数据强一致性。并结合MySQL（5.7及以上版本）并行复制特性，实现Binlog并行回放，大大降低从库延迟。

xenon的github地址为：https://github.com/radondb/xenon

1.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是基于Raft+Semi-Sync+GTID实现的高可用, 保证大多数节点接收到数据。而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. 什么是GTID

GTID(Global Transaction ID)是对于一个已提交事务的编号，并且是一个全局唯一的编号。GTID实际上是由UUID+TID组成的。其中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就会从relaylog

3、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_master=semisync_master.so;rpl_semi_sync_slave=semisync_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.3
• mysql版本: 二进制安装mysql-5.7.35
• xtrabackup: version 2.4.24

4.2. 服务器规划

服务器相关IP规划如下:

注意,这里的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 xenon3

4.4. 配置SSH互信

[mysql@xenon1 ~]# ssh-keygen [mysql@xenon1 ~]# ssh-copy-id xenon2 [mysql@xenon1 ~]# ssh-copy-id xenon3

然后在xenon2节点执行如下操作：

[mysql@xenon2 ~]# ssh-keygen [mysql@xenon2 ~]# ssh-copy-id xenon1 [mysql@xenon2 ~]# ssh-copy-id xenon3

最后，在xenon3节点执行如下操作：

[mysql@xenon3 ~]# ssh-keygen [mysql@xenon3 ~]# ssh-copy-id xenon1 [mysql@xenon3 ~]# ssh-copy-id xenon2

4.5. 配置mysql用户sudo权限

由于xenon在执行master、slave故障切换的时候，需要将vip地址也切换过去，而xenon是运行在mysql用户下的，所以需要给mysql用户做一个授权，让这个普通用户能够执行ip这个linux命令。

注意，下面的操作需要在三台mysql主机上都执行一遍。

这里以xenon1为例，修改/etc/sudoers文件，添加如下内容：

[root@xenon1 ~]# vi /etc/sudoers mysql ALL=(ALL) NOPASSWD: /usr/sbin/ip

设置完成，验证下设置是否生效，执行如下操作：

[root@xenon1 ~]# su - mysql -c "sudo ip a"

如果有本机ip地址信息输出，表示配置正确。

5、xenon以及相关软件安装

5.1. 安装mysql(二进制)

不赘述前文有提及

二进制的mysql必须安装到/usr/local目录下，解压，即可完成安装，安装完成后，还需要做一些配置工作，首先是，添加mysql配置文件，这里将mysql配置文件放到/usr/local/mysql/etc/my.cnf路径下，配置文件内容如下：

[root@xenon1 ~]# 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_bin=mysql-bin server-id=11 expire_logs_days = 10 binlog_format = row plugin-load="semisync_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_workers=4 slave_preserve_commit_order = 1 log-slave-updates

5.2. 安装xtrabackup

xtrabackup是mysql的一个热备份、恢复工具，xenon集成了xtrabackup，可以实现集群的备份和迁移，安装xtrabackup方法有很多，可以下载rpm包直接安装，也可以下载Percona提供的yum源进行安装，这里通过Percona提供的yum源进行安装，首先从https://www.percona.com/downloads/percona-release/ 下载Percona源，然后放到服务器上进行安装即可。

注意，xtrabackup也需要在三个集群节点进行安装。

这里以xenon1为例，其它节点安装方法相同，安装过程如下：

[root@xenon1 ~]# 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，安装如下:

[root@xenon1 ~]# yum install -y percona-xtrabackup-24

安装完成后，执行如下命令，可以查看版本信息：

[root@xenon1 ~]# xtrabackup --version xtrabackup: recognized server arguments: --datadir=/usr/local/mysql/data --server-id=11 --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了，过程如下：

[root@xenon1 ~]# mv xenon /usr/local/ [root@xenon1 ~]# cd /usr/local/xenon [root@xenon1 ~]# make build [root@xenon1 ~]# cd conf/ [root@xenon1 ~]# 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 GO111MODULE=off 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文件内容如下：

[root@xenon1 ~]# 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_only=0;read_only=0;sync_binlog=default;innodb_flush_log_at_trx_commit=default;rpl_semi_sync_slave_enabled=0;rpl_semi_sync_master_enabled=1", "slave-sysvars": "super_read_only=1;read_only=1;sync_binlog=1000;innodb_flush_log_at_trx_commit=2;rpl_semi_sync_slave_enabled=1;rpl_semi_sync_master_enabled=0" }, "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用户，一般是root，passwd是root用户的密码，这个密码在上面初始化mysql的时候做个设置，host保持默认的127.0.0.1即可，port默认是3306，basedir指定mysql库的程序根目录，我们这个环境是/usr/local/mysql，defaults-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用户，这里是mysql，ssh-passwd是mysql这个Linux用户的密码，ssh-port是ssh端口，默认是22，backupdir是指定通过xtrabackup进行备份时，备份数据的存放路径，xtrabackup在进行备份的时候，会首先删除这个路径下的所有数据，然后才开始备份。xtrabackup-bindir是指定xtrabackup这个命令所在的路径，默认是/usr/bin。

在xenon1节点配置完成后，在xenon2、xenon3节点也需要做相同的配置，记得修改配置文件中对应的ip地址。

6.2. 对xenon进行授权

先执行如下操作：

[root@xenon1 conf]# mkdir /etc/xenon/ [root@xenon1 conf]# cp /usr/local/xenon/conf/xenon.json /etc/xenon/ [root@xenon1 conf]# echo "/etc/xenon/xenon.json" > /usr/local/xenon/bin/config.path [root@master conf]# mkdir /usr/local/xenon/logs

注意，在xenon命令路径中，需要有一个名为config的文件，否则生成集群节点时会报错。

然后，对/usr/local/xenon和/etc/xenon/目录进行授权，允许mysql用户完全访问，操作如下：

[root@xenon1 conf]# chown mysql.mysql -R /usr/local/xenon [root@xenon1 conf]# chown mysql.mysql -R /etc/xenon/

至此，xenon配置完毕。

7、启动xenon集群与状态监控

所有配置工作完成后，就可以启动xenon集群了。首先，在172.16.213.233节点，通过mysql用户启动xenon服务，执行如下命令：

[root@xenon1 ~]# su - mysql [mysql@xenon1 ～]$ cd /usr/local/xenon/bin [mysql@xenon1 bin]$ ./xenon -c /etc/xenon/xenon.json > /usr/local/xenon/logs/xenon.log 2>&1 & [mysql@xenon1 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服务，操作如下：

[root@xenon2 ~]# su - mysql [mysql@xenon2 ~]$ cd /usr/local/xenon/bin [mysql@xenon2 bin]$ ./xenon -c /etc/xenon/xenon.json > /usr/local/xenon/logs/xenon.log 2>&1 &

然后在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变成了CANDIDATE，CANDIDATE表示候选状态，也就是说xenon集群至少有两个或以上节点加入，才能进行选举，现在加入了一个，无法完成选举，所以，接下来，还需要在172.16.213.234节点将172.16.213.233节点加入集群，才能实现master和slave的选举，在172.16.213.234节点执行如下命令：

[mysql@xenon2 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执行如下命令：

[root@xenon3 ~]# su - mysql [mysql@xenon3 ~]$ cd /usr/local/xenon/bin [mysql@xenon3 bin]$ ./xenon -c /etc/xenon/xenon.json > /usr/local/xenon/logs/xenon.log 2>&1 & [mysql@xenon3 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节点执行如下命令：

[mysql@xenon1 bin]$ ./xenoncli cluster add 172.16.213.233:8801,172.16.213.234:8801,172.16.213.235:8801

然后在172.16.213.234节点也执行相同的命令：

[mysql@xenon2 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. 监控集群状态

要查看集群状态，经常执行的命令有如下几个：

[root@xenon1 ~]# su - mysql [mysql@xenon1 ~]$ cd /usr/local/xenon/bin [mysql@xenon1 bin]$ ./xenoncli cluster status #查看集群状态 [mysql@xenon1 bin]$ ./xenoncli cluster mysql #查看集群mysql的状态 [mysql@xenon1 bin]$ ./xenoncli cluster xenon #查看跟xenon相关的角色信息和配置

其中，“xenoncli cluster status”用来查看集群整体的状态，下图是集群某时刻的一个状态截图：

从上图可以看出，此集群中每个节点的角色、mysql运行状态、Monitor引擎是否运行、主从复制状态以及目前集群leader节点是哪个，通过此命令，集群所有状态，一目了然。

“xenoncli cluster mysql”命令，主要是查看跟mysql有关的运行状态，比如每个节点mysql角色、mysql存活状态、每个节点mysql读写权限、mysql的binlog日志回放位置、主从复制状态等信息。

而“xenoncli cluster xenon”命令，主要查看跟xenon相关的角色信息以及配置信息，如下图所示：

检查集群一致状态，可执行如下命令：

[mysql@xenon1 bin]$ ./xenoncli cluster raft

注意，上面命令是在/usr/local/xenon/bin目录下执行的，如无特殊说明，执行xenoncli命令都是在/usr/local/xenon/bin目录下完成的，下面的操作都省去了 “cd /usr/local/xenon/bin”这个步骤。

检查集群 GTID 状态，可执行如下命令：

[mysql@xenon1 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. 添加/删除节点

要添加一个节点到集群，可执行如下命令：

[mysql@xenon1 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集群中删除一个节点，可以执行如下命令：

[mysql@xenon1 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命令来将此节点恢复到最新数据状态。

在要做重建的节点执行：

[mysql@xenon1 bin]$ ./xenoncli mysql rebuildme

Xenon 重建的过程，可分为如下几个阶段：

1. 禁用 raft，将 Xenon 状态设为 LEARNER；
2. 如 mysql 进程存在，则 stop mysql；
3. 清空 MySQL 数据目录；
4. 执行 xtrabackup --backup 以 xbstream 方式获取对端数据；
5. 执行 xtrabackup --prepare，应用 redo log；
6. 启动 mysql；
7. 执行 stop slave; reset slave all；
8. 执行 reset master，以 xtrabackup_binlog_info 文件中的 GTID 为准设置 gtid_purged；
9. 启用 raft，将 Xenon 状态设为 FOLLOWER 或 IDLE；
10. 等待 Xenon 自动 change master to 到主节点；
11. 执行 start slave。

在进行节点重建的时候，默认情况下，xenon会从集群节点中选取一个最新的slave节点进行数据复制和拷贝，但我们也可以指定从哪个节点进行数据的复制和拷贝，指定节点复制，重建当前 MySQL 节点，可通过如下方式：

[mysql@xenon1 bin]$ ./xenoncli mysql rebuildme --from=172.16.213.233:8801

注意，在执行节点重建时，此节点的mysql服务、xenon服务需要处于启动状态，也就是说重建的节点一定是集群的成员，否则无法执行重建，因此，故障节点在恢复重建之前，最好能通过之前的mysql备份，将mysql服务启动起来。然后执行重建。

8.4. 备份 MySQL到本地

xenon集成了备份功能，可以通过指定路径，将集群数据备份到某节点某路径下，操作命令如下所示：

[mysql@xenon1 bin]$ ./xenoncli mysql backup --to=/home/mysql/data

8.5. 关闭集群

在xenon集群每个节点，依次执行如下命令，即可关闭集群，这里以xenon1节点为例，命令如下：

[mysql@xenon1 bin]$ ./xenoncli mysql stopmonitor [mysql@xenon1 bin]$ ./xenoncli mysql shutdown [mysql@xenon1 bin]$ pkill xenon

其中，前面两个命令是关闭xenon的监控引擎、停止mysql服务，最后一个命令是关闭xenon进程。

9、xenon集群故障切换实践

9.1. 手动 Failover/switchover

xenon集群支持故障检测、故障自动切换，也支持手动触发主从切换。如果想让哪个节点成为master节点，就在哪个节点执行如下命令即可：

[mysql@xenon2 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服务 [mysql@xenon2 bin]$ ps -ef|grep xenon.json|grep -v grep|awk '{print $2}'|xargs kill -9 [mysql@xenon2 bin]$ /etc/init.d/mysqld stop #把之前mysql的data目录备份，或者删除（确认可删除情况下） [mysql@xenon2 bin]$ cd /usr/local/mysql/ [mysql@xenon2 mysql]$ mv data data.old #将备份数据拷贝到mysql的data目录下，其中备份数据路径是/home/mysql/data [mysql@xenon2 mysql]$ cp -r /home/mysql/data . #数据库恢复完成后，最后一步，启动xenon服务，mysql服务会自动启动 [mysql@xenon2 data]$ cd /usr/local/xenon/bin [mysql@xenon2 bin]$ ./xenon -c /etc/xenon/xenon.json > /usr/local/xenon/logs/xenon.log 2>&1 &

上面步骤恢复完成后，可能会自动实现master节点数据同步到此节点，那么恢复完成。但也可能出现xenon2节点主从复制失败的情况（主要是sql进程异常），失败原因是多方面的，跟使用的备份有很大关系，但解决这个问题的方法是一样的，此时需要执行第二个步骤。

第二步，如果出现了主从同步失败，那么，最快的方法，就是在这个节点执行重建，也就是在此节点执行”xenoncli mysql rebuildme“命令，但前提是此节点xenon服务和mysql服务已经正常启动。执行重建，命令如下：

[mysql@xenon2 data]$ cd /usr/local/xenon/bin [mysql@xenon2 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' doesn't exist'”，也就是说，xenon1从现在的新master的binlog拉取日志，要回放gao.k1表的数据，但是发现，xenon1库中，根本没有这个表，所以发生了报错。

这种主从复制的问题发生的几率是很高的，不同的备份，可能会出现不同的问题。

出现的问题虽多，但解决方法只有一个，要解决这个问题，最简单、直接的方法就是在此节点执行重建，过程如下：

[mysql@xenon1 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集群中，一定要定期做数据备份，这样在某节点出现问题的时候，可以通过备份来进行恢复。