数据库备份xtrabackup

XtraBackup是现今为止唯一一款为InnoDB 和XtraDB提供热备的开源工具，这个工具有以下的有点：

（1）备份快速高效而且可靠

（2）备份过程可以做到事物处理不间断

（3）节省磁盘空间和网络带宽

（4）自动备份验证

（5）恢复速度快而高效

XtraBackup适用于所有版本的Percona Server, MySQL, 和MariaDB.而且提供了流式备份，增量备份，全备份，压缩备份的功能。对于InnoDB, XtraDB, 和HailDB，XtraBackup可以实现完全无阻塞的备份。而且它对MyISAM, Merge, 和Archive等存储引擎也有很好的支持，但是在备份的末尾部分要短暂的写入时间造成不可用状态。当然官方也有一个要掏钱的工具MySQL Enterprise backup，不过大家都很少用的，功能相比XtraBackup不多，但是还是收费的，我们不排斥收费，我们只是力挺开源。

我们可以简单先看一下XtraBackup能做到那些：

（1）InnoDB 无阻塞备份，如果不是INNODB的数据表的话还是回lock table。

（2）可以为mysql提供增量备份

（3）使用流式备份将mysql备份传送到另外一台server

（4）在线在mysql数据库之间移动数据表

（5）很轻松六步创建一个复制的slave

（6）对数据库服务器没有太大负载

（7）XtraBackup 提供多种加密备份。

percona的XtraBackup 在备份的过程中是回跳过二级索引的备份，直到备份一个完整的数据库备份以后，再去重新创建二级索引，而且XtraBackup在备份中是可以导出单个表的，而且导出的表还可以在导入到percona库里（版本号大于5.1或者mysql官方大于5.6），而且在备份的时候会产生一个备份锁，是个轻量级的替代锁（替代FLUSH TABLES WITH READ LOCK）。

我们上面已经看到了XtraBackup功能的强大之处，下面看一下XtraBackup到底是怎么运行的：

其实XtraBackup也是基于INNODB的 crash-recovery功能来实现的，他是对于数据文件的直接拷贝，为了保证数据内部的一致性，就需要使用到了crash-recovery来确保恢复的数据库是一致性的，而且是可用的。mysql本身是有一个自己自身的事务日志文件，也就是redo log，也就是说当INNODB启动的时候会做两步操作，事务日志中已经提交的事物会重做，之前没有提交的事物但是已经对数据文件做了修改的就会回滚，借此来保证数据的一致性。大部分关系型数据库都是这个原理。XtraBackup 也是基于LSN( log sequence number)来工作的，每次启动备份，都会记录LSN，然后开始拷贝文件，拷贝文件是要花费一部分时间的，所以说这期间一般情况都会有数据交互，所以说所有文件也可能记录的并不是一个时间点的数据，这个时候XtraBackup 就会启动一个后台进程来观测mysql的事务日志，而且把事务日志中的改变记录下来。我们知道事物日志是回重用的（redo log）,所以说这个监控事务日志的后台进程从启动那一刻起就会不停的运作，直到备份结束。这个后台监控进程会记录所有的事务日志的改变，这些是保证数据一致性所必须的。

前面有提到，XtraBackup 在备份的时候会用一个备份锁（ Backup locks ）来取代FLUSH TABLES WITH READ LOCK，这是一个轻量级的替代锁（percona server 5.6+），XtraBackup 也会利用这个特性自动备份非INNODB表数据，可以防止阻塞DML语句的操作，当 backup locks 被支持的时候，xtrabackup 就会先拷贝INNODB的数据表，运行LOCK TABLES FOR BACKUP来拷贝MYASIM表和 .frm 文件，当拷贝结束后，在开始拷贝 .frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSM, .CSV, .par, 和.opt等文件。当然需要注意的是，备份的第一步是先完成INNODB的备份（文件和日志），LOCK TABLES FOR BACKUP只是针对非INNODB表来说的。

以上执行完毕以后，XtraBackup 会执行LOCK BINLOG FOR BACKUP来锁定日志文件用以记录在日志中的位置，或者是Exec_Master_Log_Pos 或者Exec_Gtid_Set的值，这些记录值是和SHOW MASTER/SLAVE STATUS中report的是一致的。然后停止拷贝事务日志，记录位置信息，结束以后unlock日志和表。

在恢复的准备阶段，XtraBackup 会执行crash-recovery执行备份的日志，然后将数据库启动到可用的状态。最终备份的INNODB和MYASIM表都会数据一致，INNODB表数据一致是到备份结束的时间点，而不是备份开始的时间点，因为日志是要应用到这个时间点的。这个时间点是和FLUSH TABLES WITH READ LOCK是一致的。

1.安装

#下载rpm包
rpm -ivh http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm
#安装依赖环境
yum install libev
#安装xtrabackup
yum install percona-xtrabackup-24
#用到解压缩的话，需要安装 qpress 
wget  http://www.quicklz.com/qpress-11-linux-x64.tar
tar qoress-11-linux-x64.tar
cp qpress /usr/bin

2.修改mysql配置

为了更好的备份， innodb 库要设置innodb_file_per_table=1

3.备份

#备份单个或多个库
innobackupex --default-file=/etc/my.cnf --user=root --password=xxxxxx --databases="db1 db2 db3" /备份目录

#全备份
innobackupex --default-file=/etc/my.cnf --user=root --password=xxxxxx  /备份目录

#压缩备份
innobackupex --default-file=/etc/my.cnf --user=root --password=123456 --compress /备份目录

#增量备份
#由于数据量大，我们可以采取每周一次全量备份，之后六天增量备份的机制
innobackupex --defaults-file=/etc/my.cnf  --user=root --password=123456 --incremental-basedir=/备份目录/全量备份具体路径 --incremental /备份目录

4.恢复

#如果是压缩的恢复前先解压缩
innobackupex -—decompress /备份目录/具体时间戳目录

#恢复准备
#全量恢复准备
innobackupex --apply-log --default-file=/etc/my.cnf --user=root --password=123456 /备份目录/具体时间戳目录

#增量恢复准备
innobackupex --apply-log --default-file=/etc/my.cnf --user=root --password=123456 --redo-only /全量备份目录/全量时间戳目录
innobackupex --apply-log --default-file=/etc/my.cnf --user=root --password=123456 --redo-only /全量备份目录/全量时间戳目录 --incremental-dir=/增量备份目录/增量备份时间戳目录
innobackupex --apply-log --default-file=/etc/my.cnf --user=root --password=123456 /全量备份目录/全量时间戳目录

#全量恢复与增量备份
innobackupex --copy-back --default-file=/etc/my.cnf --user=test --password=123456 /全量备份目录/全量时间戳目录