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，这个我写过http://www.cnblogs.com/shengdimaya/p/5798794.html

（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是一致的。

下面看一下怎么去Restoring 一个 backup：

我们可以使用--copy-back 或者 --move-backup参数来还原一个数据库。在还原的时候，xtrabackup 会首先去读取配置文件里面的一些参数（ datadir, innodb_data_home_dir, innodb_data_file_path, innodb_log_group_home_dir）已确定这些目录是否存在。

如果存在的话就回去执行拷贝，首先被拷贝的是MYASIM表，索引还有一些其他存储引擎的文件，接下来才会拷贝INNODB表和索引，然后是事务日志文件，在复制的时候是要保留源文件的所有属性，所以说这些目录的所有者最好是给mysql用户。但是我们要特别注意--move-back这个参数，它是会移动备份文件，而不仅仅是恢复那么简单。这样的话原来的备份就没有了，是一个很危险的操作，唯一的适用场景就是磁盘空间不足了，只能通过移动的方式来恢复，SO这个参数还是少用为妙。