MySQL全量,增量,备份基于Xtrabackup及可传输表空间实现多源数据恢复

全量备份和恢复的要点：

1. 全量备份开始时，要监听并记录redo log的变化。

2. 全量备份拷贝InnoDB数据文件时，数据库同时会写入数据，导致数据文件的新旧程度不一致。

3. 拷贝InnoDB数据文件后，对数据库施加全局读锁后，才能拷贝非事务类型的信息，比如：binlog点位、非事务类引擎的数据文件等。

4. 全量恢复时，对InnoDB数据文件的不一致，通过将步骤1中记录的redo log的变化回放，可消除步骤2中的数据文件的新旧程度不一致的问题。

在讨论增量备份和恢复时, 我们需关注以下问题：

1. 增量备份时，如何识别InnoDB的哪些数据是增量的。

2. 类似于全量备份，如何解决增量备份的数据文件的新旧不一致问题。

3. 非事务类型的信息，能否产生增量备份。

下面来图解增量备份的步骤：

由于增量备份是在全量备份的基础上进行备份，先来做一个全量备份：

讨论1：现在我们开始做一个增量备份，那么如何识别InnoDB的哪些数据是增量的？

从全量备份的示意图里，可以看到数据文件中的数据页都有LSN号（在上一篇图解中我们介绍过LSN的概念，不再赘述），LSN可以看做是数据页的变更时间戳。

那么通过这个时间戳，就可以识别数据页在全量备份后是否修改过，即通过LSN可以识别数据是否是增量的

从下图中，可以看到增量备份时，LSN>400的数据页才会进行备份。

讨论2：如果一个数据页原本不是增量范围内的，在增量备份的过程中，数据页更新了，那么增量备份是否会涵盖这个数据页？

这个问题的本质，与全量备份中的数据页新旧不一致的问题 相同，解决方案也相同：通过恢复时回放redo log，解决数据新旧不一致的问题。

也就是说：增量备份过程中，如果数据页被更新了，那数据文件中的这个数据页有可能被拷贝到备份中，也可能没有被拷贝到备份中，但这个更新信息一定会被redo log记录，并被记录在备份中。在恢复过程中，redo log会被”安全地“回放成功，达成数据的新旧一致。

下面我们来看看增量备份恢复的流程，如下图：

1. 先还原一个全量备份到临时目录（详细步骤参看上一篇图解）。

2. 开始还原增量备份，将增量备份中的增量的数据文件，覆盖到临时目录中。

3. 将增量备份中的redo log，回放到临时目录中。

4. 将其他文件覆盖到临时目录中。

5. 增备还原完成。

6. 重建redo log，为启动数据库做准备。

7. 将临时目录中的文件，拷贝到MySQL的数据目录中。

讨论3：从图中可以看到，非事务类的信息是从增量备份直接覆盖到临时目录中的，也就是说：与事务类的信息不同，MySQL没有为非事务类的信息提供增量的机制，均是全部拷贝和覆盖。

再往前一步：增量备份是否需要全局读锁呢？由讨论3的结论可知，虽然示意图上没有标明，但增量备份依然需要全局读锁去保证非事务类的信息的一致性。