基于Xtrabackup8的Mysql定时全量,增量备份及恢复实战演练

Posted 2023-04-09

参考技术A

所有mysql实例皆为MYSQL8版本,使用的Xtrabackup备份组件为xtrabackup8.

生产mysql使用基于percona的分支,相对于原版mysql多了一些性能调教和监控视图,版本为:percona-server-server-8.0.22,备份相关工具对mysql8的官方版本也是完全兼容的.percona的分支相关信息: https://www.percona.com/software/mysql-database/percona-server

生产环境mysql一共3个实例,使用MGR组成集群以实现灵活的高可用与读写分离.并由前置的proxysql进行数据的路由与转发.

模拟故障为:在生产环境mysql8 的MGR集群完全不可用,有前一天的Xtrabackup全量备份和增量备份,需要从之前的全量和增量备份完整恢复到故障最近的时间点.本次故障恢复的要求是读取前一天的所有增量和全量数据并恢复.快速重组生产MGR集群.

在这里会用ansible脚本快速搭建3个mysql实例,以模拟生产环境(略过).

backup_func.sh :

策略是每天的0:30做一次全量备份,之后每两个小时的半点会做一次增量备份.

注: 本次恢复属于完整的生产环境集群恢复,下面的 获取备份文件 , 准备备份 , 开始恢复 相关流程,需要在每一台服务器上执行,实际操作中,如果只需要恢复并查看数据则只做一个点就可以了.

这里取的是前一天的打过包的备份文件,根据备份脚本的规则,每天凌晨的全量备份之前,会自动将前一天的全量备份和增量备份目录全部打包并以前一天的日期命名:

20210609.tar.gz

将其scp到待恢复的服务器上并解压:

解压后的目录结构:

确保需要恢复的服务器有mysql实例,xtrabackup8工具已安装,由于备份是经过压缩的,确保qpress也已安装.

由于备份脚本在备份时使用了 --compress 指令,在恢复备份前,需要先解压缩备份,

这里将所有增量和全量备份路径均执行一下解压缩指令:

在同时存在全量和增量备份需要合并的情况下,准备备份时需要带上 --apply-log-only 参数,但是要注意在准备最后一个增量备份的时候,不需要加该参数.

以上操作会将所有的增量备份合并到全量备份中.

根据各自安装时指定的相关路径去删除数据.(data,binglog,logs,undolog),一般在my.cnf中有指定

如果my.cnf不是在默认路径(/etc/my.cnf),需要指定一下mysql配置文件的路径: --defaults-file=$DB_CONF

至此,备份数据在单节点上的恢复已经完成了.

查看下最后一份增量备份里才会有的一些数据

先确保同样的mysql恢复操作分别在三台服务器上执行完成.(如果在新建服务器上恢复MGR集群,一定要检查my.cnf中MGR集群相关配置,比如 loose-group_replication_local_address , loose-group_replication_group_seeds , loose-group_replication_start_on_boot )

master节点启动:
MGR的三台节点的权重实际上是一样的,选择其中的一台做master即可.

mster节点启动完成后,再分别在两台slave节点启动MGR:

由于3台mysql实例的数据是一样的,节点间状态同步迅速就OK了.

至此,3台mysql的MGR状态均为 online ,整个集群启动完成,全演练流程结束.

xtrabackup实现全量+增量+binlog恢复库

    xtrabackup是Percona公司提供的MySQL数据库备份工具，并且是惟一开源的能够对innodb和xtradb数据库进行热备的工具，它具有以下特点：

    ①备份还原过程快速、可靠；

    ②备份过程不会打断正在执行的事务；

    ③能够基于压缩等功能节约磁盘空间和流量；

    ④自动实现备份检验；

    ⑤开源，免费。

    在CentOS7上可以直接使用yum通过epel源来下载老版的xtrabackup，如果是CentOS8版本则需要通过Percona官网​​（下载选择页面：https://www.percona.com/downloads/）​​去下载xtrabackup的rpm包，并且直接使用CentOS8yum安装的MySQL为8.0版本，只能下载xtrabackup的8.0版本，其它版本不适用。

    笔者这边准备了两台CentOS8版本的虚拟机，下载了同版本的MySQL8.0.26数据库，并分别取名xtrabackup和destination。

1. ​xtrabackup实现全量备份及还原​

​1.1 下载并安装xtrabackup包​​

    通过官网下载好xtrabackup包，​​要注意的是包的版本必须和MySQL数据库版本相同​​，复制无法进行后续操作。虽然下载的是rpm包，但建议使用yum进行安装，以解决相关依赖包问题​​（如下图）​​。

 ​1.2 完全备份到/backup​

    xtrabackup主机上创建/backup目录，并进行完全备份到该目录下。由于未设置密*码，所以直接使用root账号进行备份即可，同时备份的/backup/base目录会自动创建​​（如下图）​​。

    进入到/backup/base目录下，可以看到已对数据库进行了完全备份，包括各类创建的数据库和系统自带的数据库。查看xtrabackup_binlog_info时，里面记录了我们进行完全备份是在二进制日志的哪个点；xtrabackup_checkpoints文件中记录了lsn的相关信息，对后期的增量备份尤为重要；xtrabackup_info文件的信息则更为详细，包括UUID、使用的是什么工具、工具版本、使用了什么命令等​​（如下图）​​。

​1.3 拷贝文件至目标主机​

    xtrabackup主机将整个/backup目录拷贝至destination主机。

​1.4 destination主机预准备​

    预准备可以确保数据一致，提交完成的事务，回滚未完成的事务。destination主机上执行 ​xtrabackup --prepare --target-dir=/backup/base​ 命令进行预准备，对比预准备之前的文件大小，已经从74M变成了190M​​（如下图）​​。

​1.5 复制到destination数据库​

    要保证目标主机的数据库目录为空，同时数据库状态是关闭的，执行​ xtrabackup --copy-back --target-dir=/backup/base​ 命令进行将xtrabackup主机数据库中的数据复制到本机的MySQL中​​（如下图）​​。

​1.6 还原属性​

    此时在destination主机上查看/var/lib/mysql目录，已将数据进行还原，但是所有者和所属组是root，因此还要改成mysql​​（如下图）​​。

​1.7 测试环节​

    destination主机开启mysql服务，登录数据库后，查看现有的数据库，内容与xtrabackup主机数据库中内容相同，已经完成了完全备份​​（如下图）​​。

2. ​增量备份及还原​

    要进行增量备份，必须先进行完全备份。与上面的完全备份并还原不同，在增量备份中，完全备份的数据还原过程是不能进行回滚操作的，因为在完全备份的时间点上，如果有事务正在进行，而又进行了回滚的操作，会导致复制还原的数据不全。同理，如果是做了多次的增量备份，除了最后一次的增量备份数据还原需执行回滚操作，中间节点的增量备份还原也不能进行回滚。

​2.1 完全备份到/backup​

    笔者就不重新还原系统进行操作了，xtrabackup的下载、安装及创建目录与上述完全备份都是相同的，笔者直接删除xtrabackup主机中/backup目录下的文件，同时停掉destination主机的mysql服务，并清空之前的数据，从完全备份开始演示。

    xtrabackup主机执行 ​xtrabackup -uroot --backup --target-dir=/backup/base ​命令将数据库所有数据备份到/backup目录下。

​2.2 第一次增量备份​

    假设在完全备份后，我们在hellodb数据库中的students表中添加了三条学生信息​​（如下图）​​。

    此时我们要进行增量备份，执行 ​xtrabackup -uroot --backup --target-dir=/backup/inc1 --incremental-basedir=/backup/base ​命令，即我们是基于/backup/base这个完全备份来进行的增量备份，同时增量备份是放在/backup/inc1目录下​​（如下图）​​。

​2.3 第二次增量备份​

    在完成第一次增量备份操作后，假设现在又要对hellodb数据库中的students表进行表动，再添加两条学生信息​​（如下图）​​。

    此时我们进行增量备份时不能是基于完全备份，应是基于第一次增量备份来进行的，即在/backup/inc1的基础上做的新增量备份，我们可以按次序放在/backup/inc2目录下​​（如下图）​​。

​2.4 拷贝文件至目标主机​

    与完全备份部分的操作相同，将整个/backup文件夹复制到destination主机上​​（如下图）​​。

​2.5 数据还原​

    预准备完全备份，需加上--apply-log-only选项来阻止回滚未完成的事务，否则在生产中可能会导致一些事务不全​​（如下图）​​。

    第一次增量备份的数据还原也不能进行回滚，同时要整合到完全备份中​​（如下图）​​。

    如果中间有多个增量备份，除了最后一次的增量备份还原，都不能有回滚操作，笔者这边模拟的比较简单，只有两次增量备份的数据还原，因此第二次还原时是要进行回滚，即取消--apply-log-only选项​​（如下图）​​。

​2.6 复制到destination数据库​

    因为上面的数据还原过程，已经将第一次和第二次的增量备份整合到了完全备份中，此时在destination主机上执行 ​xtrabackup --copy-back --target-dir=/backup/base​ 命令即可将所有数据复制到数据库中​​（如下图）​​。

​2.7 修改属性​

    由于/var/lib/mysql目录下的文件所有者和所属组是root，还需改成mysql​​（如下图）​​。

​2.8 测试环节​

    destination主机开启mysql服务，登录hellodb数据库后，查看students表，显示的信息与xtrabackup主机hellodb数据库中的相同，从而实现了增量备份​​（如下图）​​。

3. ​binlog还原数据​

    在完全备份和增量备份的基础上，如果xtrabackup主机的数据库再发生数据更新，继续用增量备份的话可能会导致目标主机数据库中的部分事务不全，此时可以使用binlog来进行数据还原。

    假设我们现在又对hellodb数据库中的students表进行了内容添加​​（如下图）​​。

​3.1 查看二进制日志位置​

    由于destination主机上的数据在进行第二次增量备份的还原时有回滚操作，可能会有事务不全，此时我们应该通过destination主机查看第二次增量备份整合到完全备份后的二进制日志位置​​（如下图）​​。

​3.2 发送二进制日志至目标主机​

    其他的事务都是在第二次增量备份整合到完全备份之后发生的，因此要将mysql-bin.000006二进制文件156节点后的所有数据进行还原，需要xtrabackup主机将mysql-bin.000006和之后的二进制日志文件都发送到destination主机上，由于刚好都在一个二进制日志文件上，笔者这边只发送一个即可​​（如下图）​​。

​3.3 生成并读取SQL文件​

​    ​destination主机执行 ​mysqlbinlog /backup/mysql-bin.000006 --start-position=156 > /backup/binlog.sql ​命令，将完全备份+增量备份还原数据后新增的数据添加到binlog.sql文件中，登录数据库后先关闭二进制日志，然后通过source来读取生成的SQL文件数据​​（如下图）​​。

​3.4 测试环节​

    读取完SQL文件数据，可以重新开启二进制日志，此时查看hellodb数据库中的students表，在完全备份+增量备份之后添加的两条学生信息也已经还原到destination主机数据库中​​（如下图）​​。