摘要: 相对于mysql官方的企业级InnoDB备份方案Innodb Hot Backup（物理+热备）每服务器5000刀的价格，percona公司推出的遵循GPL协议的备份利器Xtrabackup简直太赞了！这里不得不说meriaDB的作者以及percona公司，你们真乃业界良心啊！

对于很多运维同行来说，平时管理mysql除了应开的需求查询一些数据条目和监控性能外，更多的则是为了保证数据的可靠性对其进行备份和复制的操作管理， 不过最近听不少同行都说现在的互联网已经进入了缓存和nosql为王的时代，大可取代mysql这种关系型数据库，不得不承认在大量甚至海量的业务且要求数据即时响应回馈的场景中，如微信，微博，缓存和nosql的重要性和性能体现（如redis），但要说取代mysql的话，我只能表示：呵呵

其实mysqldump这种热备+逻辑的备份方式被应用的还是蛮多的，但其单线程的工作模式及生成sql写入文件的这种方式，与文件系统级别的物理备份相比，效率就显得有些差了。

这里介绍一下innodb的开源备份工具Xtrabackup，至于说其实现物理热备的原理，简单来说其理解innodb底层存储机制，类似逐页请求锁定，不会产生阻塞和按数据块来备份。percona官网对其和Innodb Hot Backup的所支持的功能和各项参数做了较详细的对比，有兴趣的朋友可以看一下，地址 http://www.percona.com/software/percona-xtrabackup，当然了，他们难免有些王婆卖瓜之嫌，但我感觉人家敢明目张胆的贴出来和Innodb Hot Backup进行叫板，而且也没被mysql官方惹上什么官司，就已经说明人家的实力了吧。如果日常工作中对mysql或者说innodb类的库操作比较多的，建议大家多了解和关注一下percona的官网。其对Xtrabackup的推荐介绍中有以下几点：

Backups that complete quickly and reliably

• Uninterrupted transaction processing during backups

• Savings on disk space and network bandwidth

• Automatic backup verification

• Higher uptime due to faster restore time

简单理解的话就是：

快速可靠的完全备份

备份过程中不会打扰到事务操作

能执行压缩数据流网络传输，有效节省带宽和磁盘资源

自动备份校验

恢复速度比较快

既然优点这么多，我们来认识和使用一下这个工具，使用之前，请确实mysql的版本为5.5+，如果安装报错类似：perl（Time：HiRes），用yum安装上即可，如果想使用其一些高级特性比较导入导出单张表，那就请在配置文件中设置innodb_file_per_table = 1（对每个新创建的表生成并使用单独的表空间）。可使用官方提供的rpm包直接安装，下载地址：   http://www.percona.com/downloads/XtraBackup/

我的操作系统环境为centos6.2_64位，mysql版本为5.5.33

yum -y install perl-Time-HiRes

rpm -ivh percona-xtrabackup-2.1.4-656.rhel6.x86_64.rpm

看一下安装的文件，其中innobackupex为主命令程序，使用时会自行判断你的mysql版本是5.5还是5.6，使用innobackupex --help可查看其使用的语法格式。

[root@gzy ~]# rpm -ql percona-xtrabackup/usr/bin/innobackupex
/usr/bin/innobackupex-1.5.1/usr/bin/xbcrypt
/usr/bin/xbstream
/usr/bin/xtrabackup
/usr/bin/xtrabackup_55
/usr/bin/xtrabackup_56
/usr/share/doc/percona-xtrabackup-2.1.4/usr/share/doc/percona-xtrabackup-2.1.4/COPYING

创建一个适用于备份操作的最小权限用户：

mysql> grant reload,lock tables,replication client on *.* to 'backup'@'localhost' identified by '123456';
Query OK, 0 rows affected (0.30 sec)mysql> flush privileges;
Query OK, 0 rows affected (0.08 sec）

接下来具体使用和测试一下备份innodb类型的库，演示一下完全+增量备份，最后用完全+增量+二进制日志恢复的过程。

innobackupex --user=backup -password=123456 /backup/

用户是之前创建的备份用户，/backup/是备份的目录，在执行过程中会打印很多执行时的信息，如果执行成功的话，最后会显示：

innobackupex: Backup created in directory '/backup/2014-02-17_01-09-48'innobackupex: MySQL binlog position: filename 'mysql-bin.000021', position 354140217 01:09:57  innobackupex: Connection to database server closed140217 01:09:57  innobackupex: completed OK!

发现了吗？自动在我们的备份目录下创建了个以当前日期和时间命名格式的目录，查看一下，发现除了备份的相关库和数据文件之外，还生成了一些xtrabackup相关文件。

[root@gzy ~]# ll /backup/2014-02-17_01-09-48/total 26664-rw-r--r--. 1 root root      260 Feb 17 01:09 backup-my.cnf-rw-r-----. 1 root root 27262976 Feb 17 01:09 ibdata1drwxr-xr-x. 2 root root     4096 Feb 17 01:09 mydbdrwxr-xr-x. 2 root root     4096 Feb 17 01:09 mysqldrwxr-xr-x. 2 root root     4096 Feb 17 01:09 performance_schemadrwxr-xr-x. 2 root root     4096 Feb 17 01:09 test-rw-r--r--. 1 root root       13 Feb 17 01:09 xtrabackup_binary-rw-r--r--. 1 root root       23 Feb 17 01:09 xtrabackup_binlog_info-rw-r-----. 1 root root       89 Feb 17 01:09 xtrabackup_checkpoints-rw-r-----. 1 root root     2560 Feb 17 01:09 xtrabackup_logfiledrwxr-xr-x. 2 root root     4096 Feb 17 01:09 zabbix

这里对其工作流程做一下说明，首先，使用innobakupex备份时，其会调用xtrabackup备份所有的InnoDB表，复制所有关于表结构定义的相关文件(.frm)、以及MyISAM、MERGE、CSV和ARCHIVE表的相关文件，同时还会备份触发器和数据库配置信息相关的文件。这些文件会被保存至一个以时间命令的目录中。

xtrabackup_checkpoints ： 备份类型（如完全或增量）、备份状态（如是否已经为prepared状态，这个为准备工作，包括事务日志和数据文件，把事务日志中已提交的事务同步至数据文件，未提交的进行回滚）和LSN(日志序列号)范围信息；每个InnoDB页(通常为16k大小)都会包含一个日志序列号，即LSN。LSN是整个数据库系统的系统版本号，每个页面相关的LSN能够表明此页面最近是如何发生改变的。查看一下其内容：

[root@gzy ~]# cd /backup/2014-02-17_01-09-48/[root@gzy 2014-02-17_01-09-48]# cat xtrabackup_checkpoints backup_type = full-backuped   # 表示备份类型为完全备份from_lsn = 0                  # LSN号从0开始to_lsn = 5618613              # LSN号到0结束last_lsn = 5618613            # 最后的lsn号，换句话说，一会进行增量备份时会以这个数字开始，可以理解为                                  xtrabackup为每次备份打的开始和结束的标记compact = 0                   # 0表示未启用压缩

xtrabackup_binlog_info： mysql服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置。这个容易理解：

[root@gzy 2014-02-17_01-09-48]# cat xtrabackup_binlog_info mysql-bin.000021  354

xtrabackup_binary：备份中用到的xtrabackup的可执行文件，因为mysql版本是5.5，所以其调用的是/usr/bin/xtrabackup_55

[root@gzy 2014-02-17_01-09-48]# cat xtrabackup_binary xtrabackup_55

backup-my.cnf：备份命令用到的配置选项信息，也就是my.cnf配置文件中定义的相关参数

[root@gzy 2014-02-17_01-09-48]# cat backup-my.cnf # This MySQL options file was generated by innobackupex.# The MySQL server[mysqld]innodb_data_file_path=ibdata1:10M:autoextendinnodb_log_files_in_group=2innodb_log_file_size=5242880innodb_fast_checksum=0innodb_page_size=16384innodb_log_block_size=512

接下来我们添加一个叫test1的用户，然后进行一次增量备份。

mysql> grant all on *.* to 'test1'@'localhost' identified by '123456';
Query OK, 0 rows affected (0.04 sec)mysql> flush privileges;
Query OK, 0 rows affected (0.07 sec)mysql> select Host,User,Password  from mysql.user;
+------------------+--------+-------------------------------------------+| Host             | User   | Password                                  |+------------------+--------+-------------------------------------------+| localhost        | root   | *2CF528CA7B474EC019B52035BDF52F143D939DBA || gzy.tongzhou.com | root   | *2CF528CA7B474EC019B52035BDF52F143D939DBA || 127.0.0.1        | root   | *2CF528CA7B474EC019B52035BDF52F143D939DBA || %                | zabbix | *2CF528CA7B474EC019B52035BDF52F143D939DBA || localhost        | backup | *6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9 || localhost        | test1  | *6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9 |+------------------+--------+-------------------------------------------+6 rows in set (0.01 sec)

每个InnoDB的页面都会包含一个LSN信息，每当相关的数据发生改变，相关的页面的LSN就会自动增长。这正是InnoDB表可以进行增量备份的基础，即innobackupex通过备份上次完全备份之后发生改变的页面来实现。

增量备份的语法： innobackupex --incremental /backup --incremental-basedir=BASEDIR

其中，BASEDIR指的是完全备份所在的目录，此命令执行结束后，innobackupex命令会在/backup目录中创建一个新的以时间命名的目录以存放此次增量备份数据。--incremental意思是类型为增量备份，另外，在执行过增量备份之后再一次进行增量备份时，其--incremental-basedir应该指向上一次的增量备份所在的目录。

innobackupex -user=backup -password=123456 --incremental /backup/ --incremental-basedir=/backup/2014-02-17_01-09-48/

备份成功会显示相关内容的，以及LSN号，备份生成的目录，及二进制日志文件及其pos点信息

xtrabackup: The latest check point (for incremental): '5618623'xtrabackup: Stopping log copying thread.
.>> log scanned up to (5618623)xtrabackup: Transaction log of lsn (5618623) to (5618623) was copied.140217 13:26:48  innobackupex: All tables unlockedinnobackupex: Backup created in directory '/backup/2014-02-17_13-26-38'  #此次增量生成的数据目录
innobackupex: MySQL binlog position: filename 'mysql-bin.000021', position 574    140217 13:26:48  innobackupex: Connection to database server closed140217 13:26:48  innobackupex: completed OK!

接下来我们再进入mysql创建一个用户test2

mysql> grant all on *.* to 'test2'@'localhost' identified by '123456';
Query OK, 0 rows affected (0.00 sec)mysql> flush privileges;
Query OK, 0 rows affected (0.01 sec)mysql> select Host,User,Password  from mysql.user;
+------------------+--------+-------------------------------------------+| Host             | User   | Password                                  |+------------------+--------+-------------------------------------------+| localhost        | root   | *2CF528CA7B474EC019B52035BDF52F143D939DBA || gzy.tongzhou.com | root   | *2CF528CA7B474EC019B52035BDF52F143D939DBA || 127.0.0.1        | root   | *2CF528CA7B474EC019B52035BDF52F143D939DBA || %                | zabbix | *2CF528CA7B474EC019B52035BDF52F143D939DBA || localhost        | backup | *6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9 || localhost        | test1  | *6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9 || localhost        | test2  | *6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9 |+------------------+--------+-------------------------------------------+7 rows in set (0.00 sec)

查看一下当前使用的二进制日志：

mysql> show master status;
+------------------+----------+--------------+------------------+| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000021 |      794 |              |                  |+------------------+----------+--------------+------------------+1 row in set (0.00 sec)

接下来把这个二进制日志备份到别处，并删除mysql的数据目录来进行恢复测试，此时并没有再进行增量备份的操作哦！（注意！！！生产环境中mysql的二进制日志文件与数据文件的有同等的重要性！所以其保存路径一定要与mysql的数据目录区分开的，且在硬件级别最少保证raid1，当然了使用mysql的复制结构如主从，多主等模型也是不可少的）

我的mysql 数据目录为/data

[root@gzy ~]# cp /data/mysql-bin.000021 /tmp[root@gzy ~]# ls /data/gzy.tongzhou.com.err  mysql             mysql-bin.000006  mysql-bin.000012  mysql-bin.000018    test
gzy.tongzhou.com.pid  mysql-bin.000001  mysql-bin.000007  mysql-bin.000013  mysql-bin.000019    zabbix
ibdata1               mysql-bin.000002  mysql-bin.000008  mysql-bin.000014  mysql-bin.000020ib_logfile0           mysql-bin.000003  mysql-bin.000009  mysql-bin.000015  mysql-bin.000021ib_logfile1           mysql-bin.000004  mysql-bin.000010  mysql-bin.000016  mysql-bin.index
mydb                  mysql-bin.000005  mysql-bin.000011  mysql-bin.000017  performance_schema

接下来停止mysql进程并删除/data......

Shutting down MySQL.... SUCCESS!
[root@gzy ~]# rm -rf /data/*[root@gzy ~]#

现在四大皆空了，接下来用刚才创建的完全备份+增量备份+二进制日志来进行恢复操作。

首先将已提交的事务进行“重放”，之后所有的增量备份数据将合并到完全备份上，所有备份数据中未提交的事务进行“回滚”。

先进行完全备份的准备：

innobackupex --apply-log --redo-only /backup/2014-02-17_01-09-48/

再进行增量备份的准备：

innobackupex --apply-log --redo-only /backup/2014-02-17_01-09-48/ --incremental-dir=/backup/2014-02-17_13-26-38/

确保2次操作都出现成功的提示：

completed OK!

因为增量备份的数据都已合并到完全备份中去了，所以此时只恢复完全备份即可

innobackupex --copy-back /backup/2014-02-17_01-09-48/

再来查看一下数据目录/data

[root@gzy ~]# ll /data/total 26644-rw-r--r--. 1 root root 27262976 Feb 17 14:10 ibdata1drwxr-xr-x. 2 root root     4096 Feb 17 14:10 mydbdrwxr-xr-x. 2 root root     4096 Feb 17 14:10 mysqldrwxr-xr-x. 2 root root     4096 Feb 17 14:10 performance_schemadrwxr-xr-x. 2 root root     4096 Feb 17 14:10 testdrwxr-xr-x. 2 root root     4096 Feb 17 14:10 zabbix

貌似恢复回来了？！好吧，把该目录的属主属组变成mysql后启动一下服务试试

[root@gzy ~]# chown mysql.mysql /data -R[root@gzy ~]# service mysqld startStarting MySQL........ SUCCESS!

提示启动成功，我们进入mysql来查看一下刚才我们所创建的测试用户是否存在：

本文出自https://my.oschina.net/u/1171265/blog/200437