XtraBackup是Percona推出的一款备份工具，算是对于mysqldump的一个补充。对于大批量数据的导入使用mysqldump会出现一定的瓶颈，这一点做过一些数据迁移项目的同学可能感同身受。
数据迁移中的数据量，小有小的好，大有大的招，见招拆招，找到适合的场景是最佳的。
如果现在去Percona官网下载，就会发现最新的版本已经是2.4.6了。下载可以选择一个完整的打包，或者逐个的rpm根据需求来安装也可以。完整的工具大概在60M左右。
而目前的MySQL版本大多都在5.5， 5.6, 对于5.7相对来说要新一些。中间会有一些时间的过渡，在多年前，可能相对来说用2.0版本一下的还比较多。
XtraBackup其实包含两个工具，一个是xtrabackup，另外一个是innobackupex。我们暂且以一个较早的版本作为演示，然后使用新版本来对比下。
# xtrabackup --version
xtrabackup version 1.6.5 for Percona Server 5.1.59
innobackupex --version
InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona Inc 2009-2012. All Rights Reserved.
可以看到这两个工具的版本还有一些差别，
xtrabackup主要是用于热备份innodb,或者是 xtradb表中数据的工具，不能备份其他类型的表，也不能备份数据表结构；
innobackupex是将xtrabackup进行封装的perl脚本，可以备份和恢复MyISAM表以及数据表结构。
所以总体来看InnoDB的使用场景虽然最为普遍，但是还得考虑到MyISAM,两者总体来说，使用innobackex的场景会多一些。
备份浅析
使用innobackupex备份，命令选项还不少，可以使用innobackupex --help来查看明细的参数使用。
比如我需要做一个全备。可以采用如下类似的方式，在备份命令中加几个辅助选项，备份使用socket连接，备份目录在/home/databak/full/20170322下。
innobackupex --socket=/home/mysql/mysql.sock /home/databak/full/20170322 --no-timestamp --no-lock --throttle=100备份后查看对应的目录，备份的数据情况如下，其中红色的几个文件是备份中额外生成的。整体看来和源库的目录结构一样。
# du -sh ./*
2.6G ./backend
4.0K ./backup-my.cnf
646M ./gm
1.0G ./ibdata1
99M ./mobile_activity
5.0G ./mobile_billing
1.1M ./mysql
2.0G ./oem_mon
212K ./performance_schema
112K ./test
4.0K ./xtrabackup_binary
4.0K ./xtrabackup_checkpoints
4.0K ./xtrabackup_logfile对于上面生成的文件，我们简单看一下。
binary结尾的文件是备份中用到的可执行文件，这个可以对应几个版本，比如xtrabackup_51,xtrabackup_55等
# more xtrabackup_binary
xtrabackup_55logfile结尾的文件的内容无法直接查看，但是可以用strings来看。通过strings解析可以看到对应的二进制日志，当然事务的Xid也有的。
# strings xtrabackup_logfile
xtrabkup 170322 16:33:40
{ ';{
';{
MySQLXid
./mysql-bin.000009
393102654
08360000000039DB下面的这个文件就更特别了，这个是作为数据的备份恢复的关键，里面有着备份恢复所有的检查点LSN,从下面的数据来看，这是一个全备，因为from_lsn=0.
# cat xtrabackup_checkpoints
backup_type = full-backuped
from_lsn = 0
to_lsn = 30754980731
last_lsn = 30754980731
而在源库的目录结构下，我们稍作过滤，也会得到一个几乎和这个工具备份出来一样的目录结构来。
# du -sh ./*|grep -v mysql-bin|grep -v innodb|grep -v log
2.6G ./backend
646M ./gm
1.0G ./ibdata1
4.5M ./ib_lru_dump
99M ./mobile_activity
5.0G ./mobile_billing
1.1M ./mysql
4.0K ./mysql.pid
0 ./mysql.sock
2.0G ./oem_mon
212K ./performance_schema
112K ./test所以xtrabackup这样一个工具就是一个热备工具，有点类似有文件级别的拷贝，但是不止于此，我们往下看。
全库恢复模拟
数据恢复是DBA最重要的工作之一，多年之前，这个“之一“的字眼还要去掉。数据无法恢复，则备份无意义。
数据的恢复还是使用innobackupex这个工具，这是参数有些差别。
这里的数据恢复分为两个步骤，prepare和还原恢复，prepare的意义就在于，如果我们备份数据的时候，存在未提交的事务，但是数据却存在于备份中，这样就是一个数据不一致的状态，在启动数据库的时候需要走一个前滚，然后是一个回滚的操作。这个体现主要就在于logfile和ibdata。是使用apply-log这个选项实现的。
我们使用如下的方式来做。
innobackupex --defaults-file=/home/databak/full/20170322/backup-my.cnf --user=root --apply-log /home/databak/full/20170322这个过程其实就会隐式调用xtrabackup_55这个可执行文件，调用的命令类似于：
xtrabackup_55 --defaults-file="/home/databak/full/20170322/backup-my.cnf"默认会使用100M的内存，也可以使用选项--use-memory来调整，整个过程会重构redo日志文件和ibdata.
这个步骤完成之后就是最关键的地方了，还原恢复。这个过程是使用copy-back的选项实现的。
innobackupex --defaults-file=/home/databak/full/20170322/backup-my.cnf --user=root --copy-back /home/databak/full/20170322整个过程就是大量的拷贝工作。
完成之后需要修改一下文件的属主，默认是root,然后启动即可。
增量备份恢复
我们接下来看看增量备份和恢复，先来创建一些数据。我们在数据库test下创建一个表test2.
> create table test2 (id int);
Query OK, 0 rows affected (0.01 sec)
> insert into test2 values(1),(2);
Query OK, 2 rows affected (0.00 sec)
Records: 2 Duplicates: 0 Warnings: 0
因为刚刚已经做了全备，我们继续做一个增备。
使用的命令如下：
innobackupex --defaults-file=/etc/my.cnf --user=root --incremental-basedir=/home/databak/incre/20170322 --incremental
/home/databak/incre/20170322但是很不幸，执行失败了。这个错误带有典型的意义。
170322 18:05:34 innobackupex: Starting ibbackup with command: xtrabackup_55 --defaults-file="/etc/my.cnf" --backup --suspend-at-end --target-dir=/home/databak/incre/20170322/2017-03-22_18-05-32 --incremental-basedir='/home/databak/incre/20170322'
innobackupex: Waiting for ibbackup (pid=4079) to suspend
innobackupex: Suspend file '/home/databak/incre/20170322/2017-03-22_18-05-32/xtrabackup_suspended'
...
xtrabackup: Error: cannot open /home/databak/incre/20170322/xtrabackup_checkpoints
xtrabackup: error: failed to read metadata from /home/databak/incre/20170322/xtrabackup_checkpoints
innobackupex: Error: ibbackup child process has died at /usr/bin/innobackupex line 349.原因就在于里面的一个关键文件 _checkpoints
使用增备得有一个参考点，从哪里开始，即从哪个LSN开始，这个LSN在指定的参数--incremental-basedir=/home/databak/incre/20170322 下不存在，因为这个是一个新目录，所以需要指向全库备份的目录。
然后修复后备份就没问题了，英为有了这个参考点LSN，所以需要要说明的是这个备份其实有累计增量和差异增量了。
这个怎么理解呢，比如周日做一个全备，周一做一个增备，周二做一个周日全备到周二的一个增备，这就是一个累计增量备份，而周三的时候做一个周二至周三数据变化的备份，就是一个差异增量备份。
下面的是一个累计增量备份。因为基准是上次的一个全备，备份后会自动生成一个目录，比如 2017-03-22_18-07-38
innobackupex --defaults-file=/etc/my.cnf --user=root --incremental-basedir=/home/databak/full/20170322 --incremental
/home/databak/incre/20170322 为了区别两次增量，我继续插入两行数据。
> insert into test2 values (3),(4);
Query OK, 2 rows affected (0.00 sec) 这样表test2就有4条数据了，每次插入2条。
下面的是一个差异增量备份。基于上一次的增备。
innobackupex --defaults-file=/etc/my.cnf --user=root --incremental-basedir=/home/databak/incre/20170322/2017-03-22_18-07-38 --incremental /home/databak/incre/20170322 整个恢复的过程是下面的形式，还是一个prepare的过程，首先是全备:
innobackupex --defaults-file=/etc/my.cnf --user=root --apply-log --redo-only /home/databak/full/20170322然后是增备，注意这里标红的参数。
innobackupex --defaults-file=/etc/my.cnf --user=root --apply-log --redo-only /home/databak/full/20170322 --incremental-dir=/home/databak/incre/20170322/2017-03-22_18-07-38这样做其实是一个merge的过程，对于增备来说，会生成如下的几个文件，都是.delta, .meta之类的文件。
[test]# ll
total 132
-rw-r--r-- 1 mysql mysql 61 Mar 22 17:58 db.opt
-rw-rw---- 1 mysql mysql 8556 Mar 22 18:03 test2.frm
-rw-r--r-- 1 root root 81920 Mar 22 18:08 test2.ibd.delta
-rw-r--r-- 1 root root 18 Mar 22 18:08 test2.ibd.meta
增备目录下的checkpoint文件就有意思了。有一个很清晰的LSN的增量描述。
[ 2017-03-22_18-07-38]# cat *checkpoints
backup_type = incremental
from_lsn = 30754980731
to_lsn = 30754984465
last_lsn = 30754984465而prepare之后的全备里面的checkpoint文件其实已经发生了变化
# cat *checkpoints
backup_type = full-prepared
from_lsn = 0
to_lsn = 30754984465
last_lsn = 30754984465这个时候我们使用如下的方式来还原恢复。
#innobackupex --defaults-file=/etc/my.cnf --user=root --copy-back /home/databak/incre/20170322/2017-03-22_18-07-38这个时候表test2里面的数据是几条？ 是2条。
这个过程我们相当于完成了一个全备+一个增备的数据恢复过程。
而我们在一个增备之后又插入了一些数据，这个怎么继续恢复呢，还是prepare的过程。这个路径需要注意，还是merge到全备中。
innobackupex --defaults-file=/etc/my.cnf --user=root --apply-log --redo-only /home/databak/full/20170322
--incremental-dir=/home/databak/incre/20170322/2017-03-22_18-11-26继续还原恢复。
innobackupex --defaults-file=/etc/my.cnf --user=root --copy-back /home/databak/full/20170322再次查看数据,我们要恢复的4条数据都恢复回来了。
> select *from test2;
+------+
| id |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
+------+
4 rows in set (0.06 sec)
备份中的选项补充
innobackupex中的选项很多，有几个还是比较有特色的，比如stream选项，--slave-info选项能够方便搭建从库，生成偏移量的信息，比如并行--parallel等，还可以根据LSN来备份，选项是--incremental-lsn
对于stream选项，默认是打包，可以结合管道来实现压缩，比如：innobackupex --defaults-file=/etc/my.cnf --user=root --stream=tar
/home/databak/full/20170322_2 | gzip >
/home/databak/full/20170322_2/20170322_2.tar.gz
备份中的常用场景
很多时候其实我不想备份整个库，我只想备份一个表，那么这个操作如何来实现呢。
innobackupex --defaults-file=/etc/my.cnf --user=root --include='test.test2' /home/databak/full/20170322_2这里有几点需要注意，工具还是会逐个去扫描，只是那些不符合的会被忽略掉，也就意味着备份出来的情况和全备的目录结构是一样的，但是指定的表会备份出ibd，frm文件。
[test]# ll
total 1036
-rw-r--r-- 1 mysql mysql 8556 Mar 22 18:34 test2.frm
-rw-r--r-- 1 root root 1048576 Mar 22 19:26 test2.ibd
[ test]# cd ../mysql
[ mysql]# ll
total 0而且有一点值得吐槽一下的是，ibdata也会完整备份出来，如果这个文件很大，那就相当不给力了。
不过也别对这种备份失去信心，有一个场景还是很实用的。那就是迁移表。
迁移表
还是刚刚的这个场景，如果表test2需要拷贝到另外一套环境中，我们可以使用Innobackupex来做物理备份，然后还原导入，达到迁移的目的。
下面的命令会声明指定目录下的备份需要导出对象。 innobackupex --apply-log --export /home/databak/full/20170322_2/2017-03-22_19-26-46这个过程的直接产物就是生成了一个.exp文件，在MySQL原生版本中是.cfg文件
[ test]# ll
total 1052
-rw-r--r-- 1 root root 16384 Mar 22 19:29 test2.exp
-rw-r--r-- 1 mysql mysql 8556 Mar 22 18:34 test2.frm
-rw-r--r-- 1 root root 1048576 Mar 22 19:26 test2.ibd对表test2做数据信息截断。
> alter table test2 discard tablespace;
Query OK, 0 rows affected (0.07 sec)然后就是物理拷贝，复制.exp文件和.ibd文件到指定目录下，修改属主权限。
然后使用import的方式即可完成导入。
> alter table test2 import tablespace;
Query OK, 0 rows affected (0.00 sec)有另外一点值得说的是，这个.exp文件是不是必须的，其实也不是。
我们只拷贝.ibd文件也照样可以。可能在新版本中会有一些警告提示，我们重新来做一下。
[test]> alter table test2 discard tablespace;
Query OK, 0 rows affected (0.03 sec)同时删除刚刚拷贝过来的.exp文件。
然后拷贝ibd文件到指定目录，赋权限
导入表空间信息。
[test]> alter table test2 import tablespace;
Query OK, 0 rows affected (0.00 sec)查看数据的情况，发现数据还是回来了。
[test]> select *from test2;
+------+
| id |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
+------+
4 rows in set (0.00 sec)当然这个过程中还是有很多需要注意的地方。