十六、mysql的备份与恢复（三）--xtrabackup(XBK、Xbackup)

xtrabackup为第三方的物理备份工具，percona公司研发，支持全备和增量备份。

一、xtrabackup的安装

#1、安装epel源和依赖包
wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo
yum -y install perl perl-devel libaio libaio-devel perl-Time-HiRes perl-DBD-MySQL libev
#2、下载软件并安装
#centos7
wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.12/binary/redhat/7/x86_64/percona-xtrabackup-24-2.4.12-1.el7.x86_64.rpm
#centos6
wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.4/binary/redhat/6/x86_64/percona-xtrabackup-24-2.4.4-1.el6.x86_64.rpm

yum -y install percona-xtrabackup-24-2.4.4-1.el7.x86_64.rpm

备份命令

xtrabackup
innobackupex    ****** 建议使用

[root@vm01 ~]# innobackupex --version
xtrabackup: recognized server arguments: --datadir=/data/mysql --server-id=201 --log_bin=mysql-bin 
innobackupex version 2.4.12 Linux (x86_64) (revision id: 170eb8c)
#innobackupex会自动记录mysql的一些参数信息

二、备份方式

物理备份

 

（1）对于非Innodb表（比如 myisam）是，锁表cp数据文件，属于一种温备份。
（2）对于Innodb的表（支持事务的），不锁表，拷贝数据页，最终以数据文件的方式保存下来，把一部分redo和undo一并备走，属于热备方式。

三、xtrabackup 在innodb表备份恢复的流程

1、xbk备份执行的瞬间,立即触发ckpt,已提交的数据脏页,从内存刷写到磁盘,并记录此时的LSN号
2、备份时，拷贝磁盘数据页，并且记录备份过程中产生的redo和undo一起拷贝走,也就是checkpoint LSN之后的日志
3、在恢复之前，模拟Innodb“自动故障恢复”的过程，将redo（前滚）与undo（回滚）进行应用
4、恢复过程是cp 备份到原来数据目录下

四、innobackupex全备份及恢复

1、全备

 

[root@vm01 backup]# innobackupex --user=root --password=123 /data/backup &>/tmp/innobackup_full.log
[root@vm01 backup]# ls
2020-12-01_05-33-01
[root@vm01 backup]# tail -5 /tmp/innobackup_full.log 
201201 05:33:03 [00]        ...done
201201 05:33:03 [00] Writing /data/backup/2020-12-01_05-33-01/xtrabackup_info
201201 05:33:03 [00]        ...done
xtrabackup: Transaction log of lsn (3712731) to (3712740) was copied.
201201 05:33:03 completed OK!
#/data/backup为备份路径

自主定制备份路径名

[root@vm01 backup]# innobackupex --user=root --password=123 --no-timestamp /data/backup/full &>/tmp/full.log
[root@vm01 backup]# innobackupex --user=root --password=123 --no-timestamp /data/backup/full &>/tmp/full.log
[root@vm01 backup]# ls
2020-12-01_05-33-01  full
[root@vm01 backup]# tail -5 /tmp/full.log 
201201 05:34:53 [00]        ...done
201201 05:34:53 [00] Writing /data/backup/full/xtrabackup_info
201201 05:34:53 [00]        ...done
xtrabackup: Transaction log of lsn (3712731) to (3712740) was copied.
201201 05:34:53 completed OK!

2、innobackupex的文件说明

源数据目录
[root@vm01 backup]# ll /data/mysql/
total 122940
-rw-r----- 1 mysql mysql       56 Nov 28 08:01 auto.cnf
-rw-r----- 1 mysql mysql      315 Nov 30 22:43 ib_buffer_pool
-rw-r----- 1 mysql mysql 12582912 Dec  1 03:16 ibdata1
-rw-r----- 1 mysql mysql 50331648 Dec  1 03:16 ib_logfile0
-rw-r----- 1 mysql mysql 50331648 Nov 28 08:01 ib_logfile1
-rw-r----- 1 mysql mysql 12582912 Dec  1 05:34 ibtmp1
drwxr-x--- 2 mysql mysql     4096 Nov 28 08:01 mysql
-rw-r----- 1 mysql mysql     1998 Dec  1 05:31 mysql-bin.000001
-rw-r----- 1 mysql mysql       19 Dec  1 03:15 mysql-bin.index
drwxr-x--- 2 mysql mysql     8192 Nov 28 08:01 performance_schema
drwxr-x--- 2 mysql mysql     8192 Nov 28 08:01 sys
-rw-r----- 1 mysql mysql        6 Nov 30 22:43 vm01.pid
drwxr-x--- 2 mysql mysql       20 Dec  1 05:25 ywx

备份目录文件
[root@vm01 backup]# ll /data/backup/full/
total 12340
-rw-r----- 1 root root      489 Dec  1 05:34 backup-my.cnf
-rw-r----- 1 root root      315 Dec  1 05:34 ib_buffer_pool
-rw-r----- 1 root root 12582912 Dec  1 05:34 ibdata1
drwxr-x--- 2 root root     4096 Dec  1 05:34 mysql
drwxr-x--- 2 root root     8192 Dec  1 05:34 performance_schema
drwxr-x--- 2 root root     8192 Dec  1 05:34 sys
-rw-r----- 1 root root       63 Dec  1 05:34 xtrabackup_binlog_info
-rw-r----- 1 root root      113 Dec  1 05:34 xtrabackup_checkpoints
-rw-r----- 1 root root      559 Dec  1 05:34 xtrabackup_info
-rw-r----- 1 root root     2560 Dec  1 05:34 xtrabackup_logfile
drwxr-x--- 2 root root       20 Dec  1 05:34 ywx

备份目录比源目录多了一下文件

-rw-r----- 1 root root       63 Dec  1 05:34 xtrabackup_binlog_info
-rw-r----- 1 root root      113 Dec  1 05:34 xtrabackup_checkpoints
-rw-r----- 1 root root      559 Dec  1 05:34 xtrabackup_info
-rw-r----- 1 root root     2560 Dec  1 05:34 xtrabackup_logfile

xtrabackup_binlog_info ：（备份时刻的binlog位置）
[root@vm01 full]# cat xtrabackup_binlog_info 
mysql-bin.000001    1998    e271e770-310c-11eb-b220-000c29d16f12:1-9

记录的是备份时刻，binlog的文件名字和当时的结束的position，可以用来作为截取binlog时的起点。

[root@vm01 full]# cat xtrabackup_checkpoints
xtrabackup_checkpoints ：
backup_type = full-backuped
from_lsn = 0          上次所到达的LSN号(对于全备就是从0开始,对于增量有别的显示方法)
to_lsn = 3712731      备份开始时间(ckpt)点数据页的LSN    
last_lsn = 3712740    备份结束后，redo日志最终的LSN
compact = 0
recover_binlog_info = 0
（1）备份时刻，立即将已经commit过的，内存中的数据页刷新到磁盘(CKPT).开始备份数据，数据文件的LSN会停留在to_lsn位置。
（2）备份时刻有可能会有其他的数据写入，已备走的数据文件就不会再发生变化了。
（3）在备份过程中，备份软件会一直监控着redo的undo，如果一旦有变化会将日志也一并备走，并记录LSN到last_lsn。
从to_lsn  ----》last_lsn 就是，备份过程中产生的数据变化.
 (4) 在备份过程中，mysql5.7中xtrabackup会占用9个LSN。及备份过程中不发生新的数据变化，last_lsn比to_lsn多9；mysql5.6为last_lsn=to_lsn

3、全备的恢复

准备备份（Prepared）

将redo进行重做，已提交的写到数据文件，未提交的使用undo回滚掉。模拟了CSR的过程
[root@vm01 full]# innobackupex --apply-log  /backup/full

恢复备份

前提：
1、被恢复的目录是空
2、被恢复的数据库的实例是关闭
systemctl stop mysqld

创建新目录

[root@vm01 full]# mkdir /data/mysql1

数据授权

chown -R mysql.mysql /data/mysql1

恢复备份

 

innobackupex --copy-back /backup/full/* /data/mysql
或
copy -a /backup/full/* /data/mysql
chown -R mysql.mysql /data/*

启动数据库

[root@vm01 full]# chown -R mysql.mysql /data/mysql1
[root@vm01 full]# systemctl start mysqld

4、--copy-back

将数据备份回原始位子，可以用copy -a或mv替代,需要注意文件的权限。

五、innobackupex 增量备份(incremental)

1、增量备份注意事宜

（1）增量备份的方式，是基于上一次备份进行增量。
（2）增量备份无法单独恢复。必须基于全备进行恢复。
（3）所有增量必须要按顺序合并到全备中。 

2、增量备份恢复

（1）删掉上次实验的备份
rm -rf /backup/*
（2）全备（周日）
innobackupex --user=root --password=123 --no-timestamp /data/backup/full &>/tmp/xbk_full.log
（3）模拟周一数据变化
create database cs charset utf8;
use cs
create table t1 (id int);
insert into t1 values(1),(2),(3);
commit;

（4）第一次增量备份（周一）
innobackupex --user=root --password=123 --no-timestamp --incremental --incremental-basedir=/data/backup/full  /data/backup/inc1 &>/tmp/inc1.log
（5）模拟周二数据
create table t2 (id int);
insert into t2 values(1),(2),(3);
commit;
（6）周二增量
 innobackupex --user=root --password=123 --no-timestamp --incremental --incremental-basedir=/data/backup/inc1  /data/backup/inc2  &>/tmp/inc2.log
（7）模拟周三数据变化
create table t3 (id int);
insert into t3 values(1),(2),(3);
commit;
drop database cs;

恢复到周三误drop之前的数据状态

恢复思路：
1.  挂出维护页，停止当天的自动备份脚本
2.  检查备份：周日full+周一inc1+周二inc2，周三的完整二进制日志
3. 进行备份整理（细节），截取关键的二进制日志（从备份——误删除之前）
4. 测试库进行备份恢复及日志恢复
5. 应用进行测试无误，开启业务
6. 此次工作的总结

恢复过程

1、关闭数据库
systemctl stop mysqld

2. 备份整理（apply-log）+合并备份（full+inc1+inc2）
(1) 全备的整理
[root@vm01 ~]# innobackupex --apply-log --redo-only /data/backup/full
(2) 合并inc1到full中
[root@vm01 ~]# innobackupex --apply-log --redo-only --incremental-dir=/data/backup/inc1 /data/backup/full
(3) 合并inc2到full中
[root@vm01 ~]# innobackupex --apply-log  --incremental-dir=/data/backup/inc2 /data/backup/full
(4) 最后一次整理全备
[root@vm01 ~]# innobackupex --apply-log  /data/backup/full

3. 截取周二 23:00 到drop 之前的 binlog 
查看最后一个增量备份的rabackup_binlog_info文件,确定binlog日志的起点
[root@vm01 inc2]# pwd
/data/backup/inc2

[root@vm01 inc2]# cat xtrabackup_binlog_info 
mysql-bin.000001    1156    e271e770-310c-11eb-b220-000c29d16f12:1-5

起点：
position:1156
gtid:e271e770-310c-11eb-b220-000c29d16f12:6

通过binlog日志确定终点

[root@vm01 backup]# mysqlbinlog --base64-output=decode-rows -vvv /data/mysql/mysql-bin.000001|tail -15
#201201  6:18:17 server id 201  end_log_pos 1574 CRC32 0x31044733     Xid = 4477
COMMIT/*!*/;
# at 1574
#201201  6:18:18 server id 201  end_log_pos 1639 CRC32 0x4dd05c28     GTID    last_committed=7    sequence_number=8    rbr_only=no
SET @@SESSION.GTID_NEXT= 'e271e770-310c-11eb-b220-000c29d16f12:8'/*!*/;
# at 1639
#201201  6:18:18 server id 201  end_log_pos 1725 CRC32 0x7104335c     Query    thread_id=54    exec_time=0    error_code=0
SET TIMESTAMP=1606774698/*!*/;
drop database cs
/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

终点为：
position:1574
gtid:e271e770-310c-11eb-b220-000c29d16f12:7

截取binlog日志
mysqlbinlog --skip-gtids --include-gtids="e271e770-310c-11eb-b220-000c29d16f12:6-7" /data/mysql/mysql-bin.000001 > /tmp/gtid.sql
mysqlbinlog --start-position=1156 --stop-position=1574 /data/mysql/mysql-bin.000001 > /tmp/bin.sql

4. 进行恢复
[root@vm01 ~]# mkdir /data/mysql/data2 -p
[root@vm01 ~]# cp -a * /data/mysql/data2
[root@vm01 ~]# chown -R mysql.mysql  /data/*
[root@vm01 ~]# systemctl stop mysqld
vim /etc/my.cnf
datadir=/data/mysql/data2
systemctl start mysqld
[(none)]>set sql_log_bin=0;
[(none)]>source /data/backup/binlog.sql
#[(none)]>source /data/backup/gtid.sql

  redo-only除最后一次增量备份外，前面的增量备份在合并的时候都需要加上这个参数，即只进行前滚，不回滚，在备份进行时有事务未提交，很可能在下次增量备份的时候提交。如果执行了回滚，后面的备份将无法使用。
  redo是物理日志，记录数据库页的改变，全备事务未提交，redo只写了一半的事务数据，假使是个大事务，需要写多个数据页，前M个数据页已写完，事务还没提交，增备的时候写完后面N个数据页，这样完整的事务是M+N的数据页，由于前M个数据页LSN未更新，增备的时候是不会备份这M个数据页的，如果应用undo，这样全备的M个数据页就会被回滚丢失，完整的事务就不是M+N个数据页了，只有增备的N个数据页，这样就丢失了M个数据页的数据。

 

3、增量备份的注意事宜--redo-only