xtrabackup实践

一：xtrabackup理论总结

• percona公司是mysql领域比较有名的咨询公司，这个公司对innoDB存储引擎进行了性能增强，被percona增强后的innoDB存储引擎叫做Percona XtraDB，Centos7中默认提供Mariadb5.5数据库，而MariadDB5.5的默认的存储引擎就是XtraDB，因为XtraDB完全兼容InnoDB，所以我们可以无差别的使用他们，在MariadDB5.5中使用show engines命令查看存储引擎时，会发现引擎的名称为InnoDB，但是对应的描述中，InnoDB却被描述为Percona-XtraDB，因为兼容，所以引擎名称为InnoDB，但是实际上我们使用的是Percona公司的XtraDB存储引擎。 
• percona也有自己的mysql分支，叫做Percona Server for MySQL，不过这里不是我们讨论的重点，我们此处要说的percona出品的一款mysql innodb数据库备份工具：XtraBackup，XtraBackup是一款免费软件，因此，它是商业备份工具InnoDB Hot Backup的一个很好的替代品，percona官网将XtraBackup与InnoDB Hot Backup进行了对比，链接如下
• https://www.percona.com/software/mysql-database/percona-xtrabackup/feature-comparison

 二：基本概念

1. xtrabackup支持对innodb进行热备、增量备份、差量备份。
2. xtrabackup支持对myisam进行温备，因为在备份myisam表时，会对myisam表添加读锁，而且不能对myisam表进行增量备份，每次备份myisam数据都是全量，即使名义上是增量，但是实际上仍然是全量。
3. 与mysqldump不同，xtrabackup是一种物理备份工具，但是，它是需要通过协议连接到mysql服务端（这一点与mysqldump相同，它们都是客户端工具，都需要连接到服务端），然后读取并复制innodb底层的"数据块"，完成所谓的"物理备份"。
4. 综上所述，xtrabackup是一种客户端工具，我们能够通过它对mysql数据库实现物理备份。

 三xtrabackup怎样实现物理备份

• xtrabackup是怎样对innodb存储引擎实现所谓的物理备份的呢？
• 如果想要搞清楚这一点，需要回顾一下innodb的存储结构，借用一张网上流传比较广的innodb逻辑存储结构图，如下

• innodb存储引擎的逻辑结构如上图所示，逻辑单元从大到小分别为:表空间(tablesapce)、段(segment)、区(extent)、页(page)、行(row)，如上图所示，每个大的逻辑单元中都包含了N个小的逻辑单元。
• 而我们只要关心上图中的extent逻辑单元和page逻辑单元即可，我们可以把上图中Extent区域中的每个"小方块(page)"当做xtrabackup需要备份的"数据块"，因为数据存放于行中，行存在于page中，所以，我们备份对应page，即可备份出对应的数据，当我们使用xtrabackup连接到mysql服务端的时候，xtrabackup会读取innodb中的page，进行备份。

四：xtrabackup怎样实现增量备份

每个Page都有自己的LSN号码，LSN是一个全局递增的号码，每次对page中的记录进行修改时，都会有对应的LSN号码，因为LSN是全局递增的，所以，LSN只会越来越大，之后的修改产生的LSN肯定比之前的操作产生的LSN大，每个page中的数据被更改时，都会在这个page中记录下本次的LSN号码，所以，如果这个page中记录的LSN越大，就证明这个Page中的数据越新（最近被修改）。

而xtrabackup就是通过LSN，实现对innodb表的增量备份的，每次备份开始时，xtrabackup会记录下当前备份到的LSN号码，当下次进行增量备份时，xtrabackup就只会拷贝出LSN大于上次记录的page，那些LSN号码小于上次记录的page则会被跳过，如果page中的LSN小于上次备份时记录的LSN号码，则证明这个page自从上次备份以来并没有被修改过，同理，如果page中的LSN大于上次备份时记录的LSN号，则证明这个page在上次备份以后，已经被修改了，所以，备份出这些page，即可实现增量备份的目的。

如果你还是没有理解，那么我们画一个简易的示意图，再来理解一遍。

假设，我们第一次备份的数据如下，所有数据由如下6个page组成，下图中的黄色方块代表page，黄色方块右上角的号码代表当前page的LSN，从下图可以看出，目前最大的LSN号码为5。

假设，备份完成后，我们修改了数据，而这次修改的数据存在于上图中的page C与page E中，所以，上图中的pageC与pageE的LSN就变成了6，因为刚才最大的LSN是5，而LSN是全局递增的，所以，如果page中的LSN越大，证明此page越新，被修改的时间越近，如下图所示

如果此时要做增量备份，那么，我们只需要备份出自上次备份以后变化的数据即可，所以，我们只要从上图中找到LSN大于5的Page，即上图中的pageC与pageE，即可得出变化的增量数据，得出上图中的增量page后，再将增量page覆盖到上次的备份中，即可得到最新的数据。

注意

当我们开始备份innodb数据时，我们还需要同时备份对应的事务日志，因为在开始备份时，有些事务已经存在于事务日志中，这些事务可能已经提交了，但是还没有同步到datafile中，所以我们要重放这些已经提交的事务，有些事务可能还未提交，所以我们要回滚这些没有提交的事务。

xtrabackup就是这样做的，在备份开始时，同时运作两个线程，一个线程负责备份innodb中的page，另一个线程负责备份innodb的事务日志（redo log），事务日志都会被xtrabackup记录到自己的日志文件中，那么，备份结束后，我们会得到两份文件，一份是不可用的备份文件，一份是备份时的事务日志，备份文件之所以不可用，是因为有一部分不确定的数据可能在事务日志中，而且热备过程中数据也可能会发生改变，所以我们要通过这两份文件，制作出一份可用的备份文件，没错，就是通过应用事务日志的方式，让最终的备份成为一个可用的备份，事务日志会被应用，事务日志文件中已经提交的事务需要replayed，未提交的事务需要roolback，  整个过程类似于mysql崩溃后恢复的过程，但是这个过程在xtrabackup中被称为"prepare"，"prepare"操作保证了备份出的数据的一致性，没有经过prepare的备份数据是不可用的，我们可以理解为如果想要得到一个可用的备份，则需要进行这些所谓的"准备"工作或者所谓的"数据恢复"的工作。

说到这里，就必须考虑另外一个问题，我们刚才提到，想要备份数据可用，则必须进行prepare工作，那么，先不考虑存在增量备份的情况，当不存在增量备份时，我们在对数据进行prepare时，需要应用事务日志，对于已经写入redologfile中但是还没有写入datafile中的已提交事务进行同步，对于未提交的的事务所作出的修改进行回滚，这是没有增量的情况下，但是，如果存在增量备份时，xtrabackup会将所有增量都合并到之前的全量上，然后使用最后的完整数据进行还原，那么，在合并数据的过程中，上一次未提交的事务有可能在下次的增量备份中已经提交了，所以，如果存在多个增量备份的时候，我们在进行prepare工作时，只需要将已经提交的事务同步到数据文件中即可，未提交的事务不用进行回滚，因为在增量中，这些事务可能已经提交了，只需要在最后一份增量数据进行prepare时，将对应的未提交的事务回滚即可。

而我们知道，xtrabackup能对innodb做热备，能对myisam做温备，对myisam做温备时会对myisam表添加读锁，也就是说，备份出的myisam表中的数据应该是一致的 ，但是如果数据库中既有myisam表又有innodb表时，如果想要整体的所有数据都一致，则只能以myisam的一致性时间点作为最终备份的一致性时间点，所以，xtrabackup在备份时，会先备份inndb数据，备份完innodb数据后，再备份非innodb数据，当我们需要将备份的数据"prepare"时，只操作innodb数据即可，非innodb数据不用动，prepare完成后，innodb的一致性时间点与非innodb数据的一致性时间点是相同的。

好了，这篇文章总结了xtrabackup中的一些理论知识，实际的操作会单独总结在其他文章中，直达链接如下