概述

今天主要通过一个实验来简单介绍一下如何用XtraBackup 实现全备&增量备份与恢复的全过程~

官方手册： https://www.percona.com/doc/percona-xtrabackup/2.4/index.html

一、xtrabackup备份过程解析

第一阶段：检查与连接的准备阶段

执行备份命令之后，备份开始，XtraBackup工具尝试去连接MySQL服务器，连接成功之后，执行MySQL版本检查，版本检查完毕。使用给定的用户、密码、端口、socket文件连接使用5.7.22版本的MySQL服务器。

第二阶段：持续拷贝redo log

这部分内容并没有在备份的输出日志里体现，推测通过开启general log可以看到，也不一定，也许要通过源码才能看到。

修正：我的测试备份环境是一个静止的数据库，在备份时，既没有发生写操作，也没有发生读操作。所以没有看到一直在做"输出看到大量log scanned up to (xxx)，对应就是持续扫描redo log"

第三阶段：拷贝ibdata1和ibd文件

xtrabackup进程开始执行一系列工作

1、调用系统函数posix_fadvise()，该函数是用来清理缓存的，不太理解此处使用的意图？了解的童鞋给我科普下，谢谢。

2、进入到/data/mysql/mysql3306/data目录下面

3、把打开文件请求限制调整为65535

4、使用以下InnoDB配置：

innodb_data_home_dir = .

#innodb数据存放在当前目录

innodb_data_file_path = ibdata1:100M:autoextend

#innodb共享表空间文件为1个，初始大小为100M，类型为自动扩展

innodb_log_group_home_dir = ./

#innodb日志文件存放在当前目录

innodb_log_files_in_group = 3

#innodb日志文件个数为3个

innodb_log_file_size = 104857600

#innodb日志文件大小为100M

5、使用O_DIRECT标志，目的为绕过缓冲区高速缓存，直接把数据传递到文件或设备，实际就是无需缓存来拷贝数据

6、默认使用单线程进行备份

7、日志扫描到2643241字节的位置

8、形成一个表表空间的列表

9、为mysql/plugin分配表空间为2，旧的最大值是0

10、把ibdata1文件拷贝到备份目录下面，直到完成

11、把ibd文件拷贝到备份目录下面，直到所有的ibd文件拷贝完成

第四阶段：备份非事务表的准备阶段

innobackupex进程开始执行一系列工作

1、扫描日志文件到2643241，这是已经写入redo的LSN

2、执行FLUSH TABLES，关闭所有打开的表，使用NO_WRITE_TO_BINLOG选项，也就是该语句不会被记录到binlog里面

3、执行FTWRL，使用全局读锁来锁定整个实例

第五阶段：备份非事务表

开始拷贝非innodb引擎表和文件，包括所有的.frm文件等，直到所有的都拷贝完成

修正：

.frm文件：保存了每个表的元数据，包括表结构的定义等；

.ibd文件：InnoDB引擎开启了独立表空间(my.ini中配置innodb_file_per_table = 1)产生的存放该表的数据和索引的文件。

第六阶段：整个备份完成后的后续工作

1、开始写xtrabackup_binlog_info文件，此处推测，获取执行过的GTID值和位点信息的语句在general log里面有记录

2、执行引擎的日志刷新，也就是把日志刷新到磁盘

3、最后的检查点是2643232字节的位置，也就是数据持久化到的LSN

4、停止拷贝线程

5、扫描日志文件到2643241

6、执行UNLOCK TABLES，释放全局读锁

7、开始拷贝ib_buffer_pool，直到拷贝完成，这是一堆数字，不知道做什么用处，了解的童鞋给我科普下，谢谢。

修正：拷贝缓冲池里的数据，以备恢复后，可以快速加载和预热访问量最高的数据。

8、打印出备份结束的位点和执行过的GTID值

9、写backup-my.cnf文件

10、写xtrabckup_info

11、LSN从2643232到2643241的事务日志拷贝完成

12、打印备份成功的标志，completed OK!

二、实验--xtrabackup全备

1、事前准备

1.1、建用户及授权

CREATE USER 'bkpuser'@'localhost' IDENTIFIED BY 'bkpuser@1234';
GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT,super ON *.* TO 'bkpuser'@'localhost';
FLUSH PRIVILEGES;

1.2、准备测试数据

CREATE DATABASE TEST;
USE TEST;
CREATE TABLE t(id int primary key, name varchar(16),insert_date datetime);
INSERT INTO t VALUES(1,'full1',now()),(2,'full2',now()),(3,'full3',now()),(4,'full4',now()),(5,'full5',now());

1.3、创建备份目录

 mkdir -p /data/backup/   

2、全备

 xtrabackup --user=bkpuser --password="bkpuser@1234" --backup --target-dir=/data/backup/

备份目录下面的各项文件说明

1）xtrabackup_checkpoints —— 备份类型（如完全或增量）、备份状态（如是否已经为prepared状态）和LSN(日志序列号)范围信息；

2）每个InnoDB页(通常为16k大小)都会包含一个日志序列号，即LSN。LSN是整个数据库系统的系统版本号，每个页面相关的LSN能够表明此页面最近是如何发生改变的。

3）xtrabackup_binlog_info —— mysql服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置。

4）xtrabackup_binlog_pos_innodb —— 二进制日志文件及用于InnoDB或XtraDB表的二进制日志文件的当前position

5）xtrabackup_binary —— 备份中用到的xtrabackup的可执行文件；

6）backup-my.cnf —— 备份命令用到的配置选项信息；

3、Preparing a backup

The xtrabackup --prepare step makes the files perfectly consistent at a single instant in time, so you can run InnoDB on them.

You can run the prepare operation on any machine; it does not need to be on the originating server or the server to which you intend to restore. You can copy the backup to a utility server and prepare it there.

 xtrabackup --prepare --target-dir=/data/backup

4、Restoring a Backup

For convenience xtrabackup binary has an xtrabackup --copy-back option, which will copy the backup to the server’s datadir:

--停止目的端数据库
systemctl stop mysqld
--删除数据文件内容
cp -rf /fsl_data/datafile/ /fsl_data/datafile_bak
rm -rf /fsl_data/datafile/*
--恢复数据库
xtrabackup --copy-back --target-dir=/data/backup
--授权
chown -R mysql:mysql datafile
chmod -R 755 datafile
systemctl restart mysqld

5、重启后校验

 systemctl restart mysqld

三、实验--xtrabackup增备

1、基于全备的增备

1.1、插入测试数据

use test;
INSERT INTO t VALUES(6,'incr_1',now()),(7,'incr_2',now());

1.2、创建目录

 mkdir -p /data/backup_incr

1.3、基于全备的增备

Now that you have a full backup, you can make an incremental backup based on it. Use the following command

开始第一次增备，只要全备和多个增备的LSN号连续，那么就可以逐个进行恢复。可以再备份目录xtrabackup_checkpoints文件中看到，其中全备的from_lsn=0,增备的from_lsn应该等于上一个增备或者全备的to_lsn

xtrabackup --user=bkpuser --password="bkpuser@1234" --backup --target-dir=/data/backup_incr \
    --incremental-basedir=/data/backup/

说明：--incremental-basedir是上次全备或者增备出来的文件夹。当第一次增备的时候，一般填上次全备，第二次增备的时候，如果--incremental-basedir填上次全备，那么本次增备就会包含上次全备到现在变化的内容，相当于oracle依次做1级，2级，3级。。。增备如果--incremental-basedir填第一次增备的目录，那么该次增备只包含第一次增备到现在的变化，文件会更小，相当于oracle rman里面每次都做1级增备。

2、基于增备的增备

2.1、插入数据

use test;
INSERT INTO t VALUES(8,'incr_incr1',now()),(9,'incr_incr2',now());

2.2、创建目录

 mkdir -p /backup/backup_incr2

2.3、基于增备的增备

xtrabackup --user=bkpuser --password="bkpuser@1234" --backup --target-dir=/data/backup_incr2 \
    --incremental-basedir=/data/backup_incr xtrabackup --user=bkpuser --password="bkpuser@1234" --backup --target-dir=/data/backup_incr2 \    --incremental-basedir=/data/backup_incr

3、prepare

这里依然要做prepare，而且是做两次prepare，第一次是把全备给prepare，不过这次和上次不一样，这次要加入--apply-log-only参数，因为在每个备份过程中，都会碰到一些事务进来执行，而备份结束时可能有些事务并没有执行完毕，所以在默认prepare中这些事务就会被回滚（rollback），而加入了--apply-log-only就不会回滚这些事务，而是等待prepare下次增备。第二次prepare就是准备第一次增备的目录，这个prepare目的就是把第一次增备期间发生的变化写入到全备的目录中去，然后第一次增备的目录就没有用处了，因为我们最终拷贝表空间文件是把增备目录拷贝过去。无论多少个增备，最后prepare的那个增备是不能加--apply-log-only参数的，因为最后一次增备还没有完成的事务就要彻底回滚来保证一致性。

3.1、prepare全备

 xtrabackup --prepare --apply-log-only --target-dir=/data/backup

3.2、prepare第一次增备

 xtrabackup --prepare --apply-log-only --target-dir=/data/backup --incremental-dir=/data/backup_incr

3.3、prepare第二次增备

 xtrabackup --prepare --target-dir=/data/backup --incremental-dir=/data/backup_incr2

4、Restoring a Backup

For convenience xtrabackup binary has an xtrabackup --copy-back option, which will copy the backup to the server’s datadir:

--停止目的端数据库
systemctl stop mysqld
--删除数据文件内容
cp -rf /fsl_data/datafile/ /fsl_data/datafile_bak
rm -rf /fsl_data/datafile/*
--恢复数据库
xtrabackup --copy-back --target-dir=/data/backup
--授权
chown -R mysql:mysql datafile
chmod -R 755 datafile
systemctl restart mysqld

5、重启后校验

 systemctl restart mysqld

觉得有用的朋友多帮忙转发哦！后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注下~