共计 8044 个字符，预计需要花费 21 分钟才能阅读完成。
这篇文章给大家介绍如何进行 MySQL 中的 xtrabackup 备份恢复，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
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) 当然这个过程中还是有很多需要注意的地方。
关于如何进行 MySQL 中的 xtrabackup 备份恢复就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
