MySQL——备份与恢复（MDP、XBK）

一、备份恢复的计划与策略

备份恢复所需要考虑的因素：
1、确认备份的表存储引擎是事务的还是非事务的，这两种在处理数据一致性上有不一样的差别。

2、考虑数据库是否需要全量备份还是增量备份。
全备优缺点：全备的意思就是能持续备份为最新状态，从数据开始进入数据库为止到一直到目前，所有的数据都备份在里面，恢复起来会比较的方便，如果数据库小可以花更少的时间进行恢复；缺点就是数据数据量过大，对系统会有一定时间的压力，而且将花费不少时间。

增量优缺点
优点：增量备份只需要备份全备之后每天或者每周生产的数据，备份时间少，对系统的压力小；
缺点：就是如果发生故障进行数据恢复需要上一次全备加上全备之后到故障时的所有二进制日志进行恢复，恢复起来时间会比较长。

3、可以使用复制的方法来做异地备份，保证数据容灾能力，但是复制不能代替备份，因为复制对于一些误操作还是不可逆的，除非有多个从库，其中有延时从库。

4、要定期的做备份，制定好做备份的计划，考虑系统所能承受的恢复时间，还有备份尽量在业务不繁忙的时候进行备份。

5、如果对于数据比较严谨的，比如那种金融性行业、证券行业，对数据比较重要的，就要保证数据库开启log-bin，保证二进制日志的记录，这样才能在有突发情况的时候进行数据的完整性恢复，基于时间，或者基于位置的去恢复数据。

6、要经常性的进行备份恢复的故障演练，保证备份以及恢复的有效性，以免发生突发情况，手忙脚乱。

备份的种类

热备：

在数据库正常对外提供服务的时候进行备份，并且能够一致性的恢复，MySQL中的话现在只支持Innodb，这种方式对数据库影响很小。

冷备：

把数据库业务关闭进行备份，数据库没有数据变化的情况下进行数据备份。

温备：

相对于表影响，会锁表，只能读不能写，影响写的操作。

二、逻辑备份与恢复

逻辑备份的特点
逻辑备份最大的优点就是各种各样的存储引擎都可以使用同样的方法来进行数据的备份，对于多种存储引擎混合的数据库来说，逻辑备份相对比较轻松。逻辑备份的话会把数据库的数据备份成文件，可以进行查看和编辑。

逻辑备份命令及参数

逻辑备份的工具

mysqldump			备份工具
mysqlbinlog			二进制工具
逻辑备份=mysqldump+mysqlbinlog

mysqldump

优点：从数据库中备份出来的是SQL文件，文本格式的可读性高，方便处理；压缩比比较高，节能磁盘空间

缺点：针对于存储引擎，需要读取数据使用SQL语句进行数据转换，比较耗费系统资源，数据量太大了效率就比较低。

注：一般100G以内的数据或者TB以上的数据进行mysqldump的使用。
相关参数

所有数据库进行备份（全备）：  -A   --all-database  
[root@hdfeng opt]# mysqldump -u root -p --all-database > /opt/mysql-backup/all.log  
[root@hdfeng opt]# mysqldump -u root -p -A > full.sql

xxx单个数据库备份：-B
[root@hdfeng opt]# mysqldump -u root -p xxx > xxx.sql	
[root@hdfeng binlog]# mysqldump -u root -p -B mysql world >/opt/mysql-backup/mysql_world.sql

xxx数据库下的某个表或多个表备份：xxx库名	tablename表名
[root@hdfeng opt]# mysqldump -u root -p xxx tablename1 tablename2 > xxx_tablename.sql 
 
本地备份和远程备份：
[root@hdfeng opt]# mysqldump -u root -p xxx -S /tmp/mysql.sock
[root@hdfeng opt]# mysqldump -u root -p xxx -h 192.168.xxx.xxx -P3306

解决备份时的警告：
[root@hdfeng opt]# mysqldump -u root -p  -A --set-gtid-purged=off >/opt/mysql-backup/full.sql;
说明：使用这条命令的意思是dump出来的备份中不包含GTID号，只备份数据也是方便导入到数据库，所以不使用。
如果是在主从中要开启，进行GTID的同步，不然的话就会从头开始生成GTID。

[root@hdfeng ~]# time mysqldump -u root -p -B mysql world --set-gtid-purged=off >/opt/mysql-backup/mysql_world.sql
Enter password:

real	0m1.849s		数据库备份时间
user	0m0.007s		CPU计算时间
sys		0m0.076s		CPU计算时间

备份mysql下除了sys,information_schema_performance_schema以外所有库，所有表的备份：
select concat("mysqldump -uroot -p123 -S /tmp/mysql.sock ",table_schema," ",table_name," >/data/backup/",table_schema,"_",table_name,".sql") from information_schema.tables where table_schema not in ('sys','information_schema','performance_schema') into outfile  '/tmp/mysqldump.sh';

特殊参数：
-R				备份存储过程及函数
--triggers		备份触发器
-E				备份事件
-F				备份开始，刷新出来新的binlog日志
注：除了sys，information_schema,performance_schema这三个库，在数据库中每有一个库就会刷新一个binlog日志。
[root@hdfeng ~]# mysqldump -uroot -p -A -R -E --triggers >/opt/mysql-backup/full.sql	

特殊技巧：
从mysqldump 全备文件中获取 库和表的备份，主要用于数据备份过大，但是需要恢复的数据不多，只有几M或者只有几条insert数据。

1、从sql备份中获得表结构
# sed -e'/./{H;$!d;}' -e 'x;/CREATE TABLE `city`/!d;q'  full.sql>createtable.sql

2、获得备份中的INSERT INTO语句，用于数据的恢复

# grep -i 'INSERT INTO `city`'  full.sqll >data.sql &

3.获取单库的备份

# sed -n '/^-- Current Database: `world`/,/^-- Current Database: `/p' all.sql >world.sql

辅助参数

-F 参数:在备份完以后刷新一个新的binlog日志
--master-data=0,1,2	
0  默认
1  以change master to命令形式写入到备份文件，可以用作主从复制
会在备份文件中多这么一句：
--change master to master_log_file='mysql-bin.000001',master_log_pos=xxx;
2  用注释的形式保存position到备份文件里面

--single-transaction
InnoDB表的快照备份功能：
1、不加参数，启动所有表的温备，所有的表都会进行锁表
2、加参数，对InnoDB表进行快照备份，其它的进行自动锁表
例：
mysqldump -uroot -p -A -R -E --triggers --master-data=2 --single-transaction --set-gtid-purged=OFF >/opt/data/backup/alldatabase.sql

--set-gtid-purged=OFF,auto,on
OFF		表示备份的时候不备份GTID号，在新库中去恢复的时候新库会从头开始生成GTID号，一般在日常备份中用
ON		会记录GTID，在主从复制的时候使用
auto	默认值，也会记录GTID，在主从复制的时候使用
--max_allowed_packet=256M
The maximum packet length to send to or receive from server.
如果在业务中备份的时候表的数据量非常大，会报这个错误，可以在备份的时候直接加这个参数。
比如几千万行的数据，如果是默认的值，是直接会报错的。
默认大小：
mysql [(none)]>select @@max_allowed_packet;
+----------------------+
| @@max_allowed_packet |
+----------------------+
|              4194304 |
+----------------------+
1 row in set (0.00 sec)
mysqldump -uroot -p -A -R -E --triggers --master-data=2 --single-transaction 
--set-gtid-purged=OFF --max-allowed-packet=256M >/opt/mysql-data/alldatabase.sql


--max-allowed-packet=#
The maximum packet length to send to or receive from server.

实现所有表的单独备份：

select concat("mysqldump -uroot -p123 ",table_schema," ",table_name," --master-data=2 
--single-transaction --set-gtid-purged=OFF  -R -E --triggers >/backup/",table_schema,"_",table_name,".sql") from information_schema.tables
 where table_schema not in ('sys','information_schema','performance_schema');

基于逻辑备份的恢复操作

完全恢复

语法：

mysql -uroot -p  database < backupfile.sql
当恢复的数据不完整的时候，再进行备份与日志一起恢复：
mysqlbinlog mysql-bin.000001 | mysql -uroot -p database

备份恢复案例

每周三11点进行备份：

mysqldump -uroot -p --single-transaction -F test >/opt/mysql-data/test.sql
查看备份的数据：
 [test]>select * from t1;
+------+---------+
| id   | sname   |
+------+---------+
|    1 | 234re   |
|    2 | 2r3fewd |
|    3 | 23rfe   |
|    4 | 23refd  |
|    5 | 23ref   |
+------+---------+
5 rows in set (0.00 sec)
如果数据量过于庞大，可以使用：
[root@hdfeng opt]# mysqlshow -uroot test --count -p
Enter password:
Database: test
+---------------+----------+------------+
|    Tables     | Columns  | Total Rows |
+---------------+----------+------------+
| collection_1  |        3 |          0 |
| collection_10 |        3 |          0 |
| collection_11 |        3 |          0 |
| collection_12 |        3 |          0 |
| collection_2  |        3 |          0 |
| collection_3  |        3 |          0 |
| collection_4  |        3 |          0 |
| collection_5  |        3 |          0 |
| collection_6  |        3 |          0 |
| collection_7  |        3 |          0 |
| collection_8  |        3 |          0 |
| collection_9  |        3 |          0 |
| t1            |        2 |          5 |
+---------------+----------+------------+
13 rows in set.
去查看数据量的行数，来保证数据的准确性
然后备份完毕之后又插入了几条数据：
[test]>insert into t1 values(6,'234256223rfe'),(7,'23rfed2rfe');
Query OK, 2 rows affected (0.01 sec)
Records: 2  Duplicates: 0  Warnings: 0
下午3点发生故障，数据库无法访问了，需要恢复备份的数据：
mysql -uroot -p test < /opt/mysql-data/test.sql
因为备份之后还有数据进来，所以还需要恢复备份之后的数据：
mysqlbinlog mysql-bin.000001 | mysql -uroot -p test
恢复完成之后进行查看：
[test]>select * from t1;
+------+--------------+
| id   | sname        |
+------+--------------+
|    1 | 234re        |
|    2 | 2r3fewd      |
|    3 | 23rfe        |
|    4 | 23refd       |
|    5 | 23ref        |
|    1 | 234256223rfe |
|    2 | 23rfed2rfe   |
+------+--------------+
7 rows in set (0.00 sec)
已成功恢复！

基于时间恢复

其实基于时间点的恢复的话，会对数据造成一定的不准确性，因为你不知道在发生故障的时候，发生了多少事务，所以如果基于时间去恢复的话会恢复的没那么准确，有可能会有一些事务会进行遗漏，所以一般的话我不是很推荐在生产环境中用这种方法去恢复数据。
基于时间恢复的操作：

将binlog与备份一起恢复到故障前：
mysqlbinlog --stop-date="2020-03-04 14:59:59" /opt/mysql-data/binlog/mysql-bin.000001 | mysql -uroot -p
继续执行故障后的binlog进行恢复
mysqlbinlog --start-date="2020-03-04 15:01:00" /opt/mysql-data/binlog/mysql-bin.000001 | mysql -uroot -p
基于时间进行恢复，可能会丢失15：00到15：01分这1分钟的binlog日志所以更精确的恢复数据应当在binlog中输出在故障之后的日志按GTID号进行恢复，也能基于position号进行恢复，也就是基于位置进行恢复。

基于位置进行恢复

基于位置的恢复

截取备份前后10分钟的日志：
mysqlbinlog --start-date="2020-03-04 14:55:00" --stop-date="2020-03-04 15:05:00" /opt/mysql-data/binlog/mysql-bin.000001 >/tmp/binlog_restore.sql 

进行备份恢复以后，再进行确实日志的恢复：
假设position号错误语句号是872-920，应该往前一位开始停止恢复，所以是停止恢复到872，因为不需要恢复错误的语句，所以应该是恢复到错误之前，然后错误之后的就是920开始恢复错误语句后的日志。这个日志每个人的记录都不一样，需要自己去找。上节binlog里面有讲解如何寻找。

mysqlbinlog --stop-position="872" /opt/mysql-data/binlog/mysql-bin.000001 | mysql -uroot -p 
mysqlbinlog --start-position="920" /opt/mysql-data/binlog/mysql-bin.000001 | mysql -uroot -p

并行恢复

并行恢复的话会使用到mydumper，配套使用myloader工具进行数据的恢复，能大大的减少恢复的时间。

[test1]>select count(1) from collection_1;
+----------+
| count(1) |
+----------+
|   120000 |
+----------+
1 row in set (0.04 sec)
[test1]>delete from collection_1 limit 50;
删除以后进行恢复：
[root@test tmp]# myloader -uroot -p -S /tmp/mysql.sock -d /tmp/test1.sql -B test1 -t 3 -o
恢复完成以后再看数据量，恢复成功！
[test1]>select count(1) from collection_1;
+----------+
| count(1) |
+----------+
|   120000 |
+----------+
1 row in set (0.04 sec)

三、物理备份与恢复

物理备份的话也分为冷备份与热备份两种，和逻辑备份比的话他的备份恢复速度会更快，物理备份也可以理解为物理层面文件的CP，下面就是物理备份的一些使用方法和命令。

物理备份的命令及参数

物理备份的工具

基于磁盘文件进行备份

xtrabackup(XBK)					percona公司的软件
MySQL Enterprise Backup(MEB)	MySQL官方
物理备份=
xtrabackup-full+xtrabackup-incr+binlog
或
xtrabackup-full+binlog

xtrabackup全备

优点：从磁盘层面去进行备份，不用管SQL的逻辑结构，性能比较高，支持全备，支持增量。

缺点：备份的数据可读性比较差，压缩比不高，比较占用磁盘空间。

注：一般的话建议使用在几百G的数据库中比较方便。

增量备份的理解：增量备份之前肯定需要一份全备，增量备份就是备份每天全备以外增长的一些新的数据，这个就是增量备份。（innodb支持热备、其它表支持温备）

xtrabackup备份innodb：拷贝数据页备份数据的同时还会备走redo、undo日志

xtrabackup备份非innodb表：锁表CP数据，属于温备

开始安装：
下载地址：https://www.percona.com/downloads/percona-toolkit/LATEST/
percona-xtrabackup-24-2.4.12-1.el7.x86_64.rpm
或者也可以wget下载

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 rsync
安装完依赖以后安装我们的软件
[root@hdfeng opt]# rpm  -ivh percona-xtrabackup-24-2.4.12-1.el7.x86_64.rpm
警告：percona-xtrabackup-24-2.4.12-1.el7.x86_64.rpm: 头V4 DSA/SHA1 Signature, 密钥 ID cd2efd2a: NOKEY
准备中...                          ################################# [100%]
正在升级/安装...
   1:percona-xtrabackup-24-2.4.12-1.el################################# [100%]
(如果安装不上用：yum -y install percona-xtrabackup-24-2.4.4-1.el7.x86_64.rpm
安装，自动检查相关依赖)
安装完成！

安装完成以后一共有两个命令：
xtrabackup
innobackupex 重点使用
相关版本查看：

[root@hdfeng opt]# innobackupex --version
xtrabackup: recognized server arguments: --datadir=/opt/mysql-data/mysql --server-id=6 --log_bin=/opt/mysql-data/binlog/mysql-bin --innodb_flush_method=fsync
innobackupex version 2.4.12 Linux (x86_64) (revision id: 170eb8c)
会自己读取/etc/my.cnf下的一些配置信息，主要就是备这个下面的数据，也可以自己指定。

进行数据备份：

[root@hdfeng backup]# innobackupex --user=root --password=123 /opt/mysql-data/backup/
xtrabackup: recognized server arguments: --datadir=/opt/mysql-data/mysql --server-id=6 --log_bin=/opt/mysql-data/binlog/mysql-bin --innodb_flush_method=fsync
xtrabackup: recognized client arguments: --datadir=/opt/mysql-data/mysql --server-id=6 --log_bin=/opt/mysql-data/binlog/mysql-bin --innodb_flush_method=fsync
200310 10:58:42 innobackupex: Starting the backup operation

IMPORTANT: Please check that the backup run completes successfully.
           At the end of a successful backup run innobackupex
           prints "completed OK!".

200310 10:58:42  version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup' as 'root'  (using password: YES).
Failed to connect to MySQL server: DBI connect(';mysql_read_default_group=xtrabackup','root',...) failed: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) at - line 1314.
200310 10:58:42 Connecting to MySQL server host: localhost, user: root, password: set, port: not set, socket: not set	
Failed to connect to MySQL server: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2).
如果遇到以上报错，是因为他无法找到socket文件所以需要指定clinet端的socket文件：
vim /etc/my.cnf
添加
[client]
socket=/tmp/mysql.sock
保存退出再进行备份
[root@hdfeng backup]# innobackupex --user=root --password=123 /opt/mysql-data/backup/
.200310 11:01:50 >> log scanned up to (228166604)

200310 11:01:50 Executing UNLOCK TABLES
200310 11:01:50 All tables unlocked
200310 11:01:50 [00] Copying ib_buffer_pool to /opt/mysql-data/backup/2020-03-10_11-01-40/ib_buffer_pool
200310 11:01:50 [00]        ...done
200310 11:01:50 Backup created in directory '/opt/mysql-data/backup/2020-03-10_11-01-40/'
MySQL binlog position: filename 'mysql-bin.000009', position '1882', GTID of the last change '979de5b8-3c01-11ea-8252-000c29b6e0ec:1-383'
200310 11:01:50 [00] Writing /opt/mysql-data/backup/2020-03-10_11-01-40/backup-my.cnf
200310 11:01:50 [00]        ...done
200310 11:01:50 [00] Writing /opt/mysql-data/backup/2020-03-10_11-01-40/xtrabackup_info
200310 11:01:50 [00]        ...done
xtrabackup: Transaction log of lsn (228166595) to (228166604) was copied.
200310 11:01:50 completed OK!



再进行备份，出现以上信息，备份成功了，再检查一下备份文件，数据也有了，这样才算备份成功！
[root@hdfeng backup]# du -sh *
0	2020-03-10_10-58-42
192M	2020-03-10_11-01-40
如果不想生成日志信息，把日志进行输出
[root@hdfeng backup]# innobackupex --user=root --password=123 /opt/mysql-data/backup/ &>/tmp/xtrabackup.log

备份出来的文件查看：
[root@hdfeng 2020-03-10_11-01-40]# ll -h
总用量 77M
-rw-r-----. 1 root root  487 3月  10 11:01 backup-my.cnf
drwxr-x---. 2 root root 4.0K 3月  10 11:01 clevercore
drwxr-x---. 2 root root   46 3月  10 11:01 gtid
-rw-r-----. 1 root root  934 3月  10 11:01 ib_buffer_pool
-rw-r-----. 1 root root  76M 3月  10 11:01 ibdata1
drwxr-x---. 2 root root 4.0K 3月  10 11:01 mysql
drwxr-x---. 2 root root 4.0K 3月  10 11:01 pavtcore
drwxr-x---. 2 root root 8.0K 3月  10 11:01 performance_schema
drwxr-x---. 2 root root 8.0K 3月  10 11:01 sys
drwxr-x---. 2 root root 4.0K 3月  10 11:01 test
drwxr-x---. 2 root root  107 3月  10 11:01 test_database1
drwxr-x---. 2 root root  107 3月  10 11:01 test_database2
drwxr-x---. 2 root root  144 3月  10 11:01 world
-rw-r-----. 1 root root   65 3月  10 11:01 xtrabackup_binlog_info
-rw-r-----. 1 root root  117 3月  10 11:01 xtrabackup_checkpoints
-rw-r-----. 1 root root  554 3月  10 11:01 xtrabackup_info
-rw-r-----. 1 root root 2.5K 3月  10 11:01 xtrabackup_logfile
drwxr-x---. 2 root root  150 3月  10 11:01 youngboy
其它的都是一些数据文件以及库，在存储引擎中已经都有介绍过了，主要来看这xtrabackup开头的4个文件：
xtrabackup_binlog_info：
[root@hdfeng 2020-03-10_11-01-40]# cat xtrabackup_binlog_info
mysql-bin.000009	1882	979de5b8-3c01-11ea-8252-000c29b6e0ec:1-383
这个里面的内容记录的是备份时候的binlog日志的日志文件以及当时备份结束的position号和gtid号

xtrabackup_checkpoints：
[root@hdfeng 2020-03-10_11-01-40]# cat xtrabackup_checkpoints
backup_type = full-backuped			备份类型
from_lsn = 0						备份文件从哪里开始备份的LSN号
to_lsn = 228166595					开始备份的LSN号
last_lsn = 228166604				结束备份的LSN号
compact = 0
recover_binlog_info = 0
其实xbk备份的时候会占用9个LSN号，所以看以上to_lsn和last_lsn其实是一样的，中间没有数据进行操作的。

xtrabackup_info：
[root@hdfeng 2020-03-10_11-01-40]# cat xtrabackup_info
uuid = 7d1208df-627b-11ea-be0f-000c29b6e0ec
name =
tool_name = innobackupex
tool_command = --user=root --password=... /opt/mysql-data/backup/
tool_version = 2.4.12
ibbackup_version = 2.4.12
server_version = 5.7.20-log
start_time = 2020-03-10 11:01:48
end_time = 2020-03-10 11:01:50
lock_time = 0
binlog_pos = filename 'mysql-bin.000009', position '1882', GTID of the last change '979de5b8-3c01-11ea-8252-000c29b6e0ec:1-383'
innodb_from_lsn = 0
innodb_to_lsn = 228166595
partial = N
incremental = N
format = file
compact = N
compressed = N
encrypted = N
备份一些比较详细的数据库信息，包括备份的时间、位置、版本、工具等等。

xtrabackup_logfile：二进制日志，用来记录备份过程中的redo和undo日志，无法查看

自己定制备份名：

--no-timestamp这个参数
[root@hdfeng 2020-03-10_11-01-40]# innobackupex --user=root --password=123 --no-timestamp /opt/mysql-backup/full &>/tmp/xtrabackup.log

xtrabackup全备的恢复：

假设数据库崩了
[root@hdfeng full]# ps -ef | grep mysqld
mysql      1110      1  0 3月09 ?       00:01:10 /opt/mysql-basedir/mysql/bin/mysqld --defaults-file=/etc/my.cnf
root       2976   2688  0 11:40 pts/0    00:00:00 grep --color=auto mysqld
[root@hdfeng mysql]# kill -9 1110
[root@hdfeng full]# ps -ef | grep mysqld
root       2981   2688  0 11:40 pts/0    00:00:00 grep --color=auto mysqld
[root@hdfeng mysql]# ls
auto.cnf    gtid            ibdata1      ib_logfile1  pavtcore            slow.log  test            test_database2  youngboy
clevercore  ib_buffer_pool  ib_logfile0  mysql        performance_schema  sys       test_database1  world
[root@hdfeng mysql]# rm -rf *
数据文件也全没了，只有一个全备了
进行redo的前滚恢复：
[root@hdfeng mysql]# innobackupex --apply-log /opt/mysql-backup/full
--apply-log自动会去找xtrabackup_profile文件进行redo前滚操作
InnoDB: Shutdown completed; log sequence number 228167720
200310 11:44:51 completed OK!
最后出现这个表示成功！
进行数据恢复操作：
[root@hdfeng mysql]# innobackupex --copy-back /opt/mysql-backup/full
 200310 11:57:51 [01] Copying ./ibtmp1 to /opt/mysql-data/mysql/ibtmp1
200310 11:57:51 [01]        ...done
200310 11:57:51 completed OK!
最后出现这个表示恢复成功！
然后再给数据权限启动数据库：
[root@hdfeng mysql]# chown -R mysql.mysql /opt/mysql-data/*
[root@hdfeng mysql]# systemctl start mysqld
[root@hdfeng mysql]# mysql -uroot -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.7.20-log MySQL Community Server (GPL)

Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

[(none)]>
数据库恢复完成！

xtrabackup增量备份

增量备份实验：

进行日志清空
[(none)]>reset master;
Query OK, 0 rows affected (0.02 sec)
查看环境是否清除
[(none)]>show master status ;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 |      154 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)
建库建表：
[(none)]>create database test charset utf8mb4;
Query OK, 1 row affected (0.00 sec)
[test]>create table collection(id int );
Query OK, 0 rows affected (0.02 sec)
[test]>insert into collection values(1),(2),(3),(4),(5);
Query OK, 5 rows affected (0.01 sec)
Records: 5  Duplicates: 0  Warnings: 0
[test]>commit;
Query OK, 0 rows affected (0.00 sec)
1、模拟全备：
[root@hdfeng backup]# innobackupex --user=root --password=123 --no-timestamp /opt/mysql-data/backup/full &>/tmp/xtrabackup.log
2、模拟全备后的数据输入：
[(none)]>use test;create table collection2(id int );
Query OK, 0 rows affected (0.02 sec)
[test]>insert into collection2 values(1),(2),(3),(4),(5);
Query OK, 5 rows affected (0.00 sec)
Records: 5  Duplicates: 0  Warnings: 0
[test]>commit;
Query OK, 0 rows affected (0.00 sec)
3、基于全备以后的增量备份：
[root@test backup]# innobackupex --user=root --password=123 --no-timestamp --incremental /opt/backup/increment1 --incremental-basedir=/opt/backup/full &>/tmp/xtrabackup.log
4、模拟第二次数据输入：
[(none)]>use test;
[test]>create table collection3 (id int);
insert into collection3 values(1),(2),(3),(4),(5);
commit;
5、进行第二次增量备份：
[root@test backup]# innobackupex --user=root --password=123 --no-timestamp --incremental /opt/backup/increment2 --incremental-basedir=/opt/backup/increment1 &>/tmp/inc2.log
6、模拟第三次数据输入：
[(none)]>use test;
[test]>insert into collection3 values(6),(7),(8),(9),(10);
[test]>update collection3 set id=20 where id=10;
[test]>commit;
[test]>drop database test;

恢复方案：
1、增量备份需要配合全备使用（使用LSN号合并到全备），不能单独恢复
2、所有备份都必须–apply-log进行备份整理
3、部分备份只需要进行redo，不需要进行undo（–redo-only）
–redo-only
This option should be used when preparing the base full
backup and when merging all incrementals except the last one.
表示最后一个增量需要进行回滚undo操作，如果前面的增量进行了回滚，LSN号会乱掉
开始恢复：

[root@test backup]# innobackupex --apply-log --redo-only /opt/backup/full/
进行全备的日志整理
[root@test backup]# innobackupex --apply-log --redo-only --incremental-dir=/opt/backup/increment1 /opt/backup/full/
进行增量备份的合并,合并到全备中
[root@test backup]# innobackupex --apply-log  --incremental-dir=/opt/backup/increment2 /opt/backup/full/
进行增量备份最后一次的合并
然后再进行全备数据的undo操作,因为全备中的日志和第一次增量的备份还没有进行回滚
[root@test backup]# innobackupex --apply-log /opt/backup/full/
进行二进制日志的截取，恢复第三次操作删库前操作的数据：
1、需要判断起点，去看increment2文件中的xtrabackup_binlog_info这个里面的position就是起点（我的起点为1061）
2、判断终点，去对应的binlog日志中查看事件，找出删除库之前的position号或GTID号即可
show binlog events in 'mysql-bin.000002';我的为1676到删除前的position号
[root@test backup]# mysqlbinlog --start-position=1061 --stop-position=1676  /opt/mysql-data/mysql/mysql-bin.000002 >/tmp/test_3.sql
准备新的环境进行数据的恢复：
初始化一个数据库实例
然后进行xtrabackup备份恢复
[root@test mysql3308]# cp -a /opt/backup/full/* /opt/mysql3308/mysql/
拷贝数据到新库，并且授权，然后启动数据库
[root@test mysql]# chown -R mysql.mysql *
[root@test mysql]# systemctl start mysqld3308
[root@test mysql]# mysql -uroot -p -S /opt/mysql3308/mysql/mysql.sock
Enter password:
[(none)]>use test;
[test]>show tables;
+----------------+
| Tables_in_test |
+----------------+
| collection     |
| collection2    |
| collection3    |
+----------------+
3 rows in set (0.00 sec)
[test]>select * from collection3;
+------+
| id   |
+------+
|    1 |
|    2 |
|    3 |
|    4 |
|    5 |
+------+
5 rows in set (0.00 sec)
到第三次之前的数据恢复成功！
接下来恢复第三次删库前的数据：
[test]>set sql_log_bin=0;
[test]>source /tmp/test_3.sql;
Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)
[test]>select * from collection3;
+------+
| id   |
+------+
|    1 |
|    2 |
|    3 |
|    4 |
|    5 |
|    6 |
|    7 |
|    8 |
|    9 |
|   20 |
+------+
10 rows in set (0.00 sec)
恢复成功！

xbk的单表备份恢复的话就需要用到表迁移用xbk把数据备份出来，然后通过discard，import命令进行数据的恢复！