XtraBackup流程【DBA面试系列】

向右看齐 2023-07-05 13:28 1阅读 0赞

### 文章目录 ###

*  XtraBackup
 *   *  全备
     *   *  全量备份流程总结
         *  FAQ
     *  全备恢复
     *   *  全备还原流程
         *  FAQ
     *  增量备份
     *   *  FAQ
     *  增备恢复
     *   *  增量备份流程总结
         *  FAQ

# XtraBackup #

## 全备 ##

Innobackupex全备流程

1. 连接mysql

2. 读取配置文件,找到相应的数据和日志位置

3. start xtrabackup\_log:创建xtrabackup\_logfile文件.模拟mysql instance方式,以读写模式打开并读取redolog,检查到当前checkpoint点,从当前checkpoint点位置开始复制redolog,同时持续扫描redolog,有新的redolog数据就复制到xtrabackup\_logfile文件中

4. 复制innodb引擎表的:.ibd/.ibdata1/undo logs等文件

5. 执行Flush NO\_WRITE\_TO\_BINLOG TABLE/flush tables with read lock

6. 复制非Innodb引擎的表.MYD/.MYI/.frm/.opt/misc等文件和innodb引擎表的.frm/.opt/misc等文件

7. 获取二进制日志文件位置或GTID,并写到xtrabackup\_binlog\_info文件

8. 执行FLUSH NO\_WRITE\_TO\_BINLOG ENGINE LOGS语句

9. 停止日志复制线程 <复制redolog的线程>

10. 执行UNLOCK TABLES语句

11. 最后,生成backup-my.cnf/xtrabackup\_info等文件

说明

*  步骤5. FTWRL加的只读S锁，原因，方式读取数据时发生DDL操作，并获取binlog位置，redo日志暂时也会卡在这里
 *  步骤8. 执行FLUSH NO\_WRITE\_TO\_BINLOG ENGINE LOGS语句将innodb层的redolog持久化到磁盘后进行复制（因为xtrabackup并不备份二进制日志，如果这个过程出现问题，就导致恢复之后丢失redolog中的数据，做主从复制可能会同步出错），然后停止读redolog复制线程，innobackupex备份数据的时间点是停止redolog复制时的数据对应的时间点

### 全量备份流程总结 ###

1.  复制已有的redo log，然后监听redo log变化并持续复制
2.  复制事务引擎数据文件
3.  等到数据文件复制完成
4.  加锁：全局读锁
5.  备份非事务引擎数据文件及其他文件
6.  获取binlog点位信息等元数据
7.  停止复制redo log
8.  解锁：全局读锁
9.  复制buffer pool dump
10. 备份完成

### FAQ ###

1.  为什么要先复制redo log，而不是直接开始复制数据文件？

因为XtraBackup是基于InnoDB的crash recovery机制进行工作的。如上图2中的页2，由于是热备操作，在备份过程中可能有持续的数据写入，直接复制出来的数据文件可能有缺失或被修改的页，而redo log记录了InnoDB引擎的所有事务日志，可以在还原时应用redo log来补全数据文件中缺失或修改的页。所以为了确保redo log一定包含备份过程中涉及的数据页，需要首先开始复制redo log。

1.  加全局读锁的作用？

因为要保证”非事务资源 自身的一致性“ 和 ”非事务资源与 事务资源的一致性“。在加锁期间，没有新数据写入，XtraBackup会复制此时的binlog位置信息，frm表结构，MyISAM等非事务表。

1.  为什么要先停止复制redo log，再解锁全局读锁？

也是因为要保证“非事务资源与事务资源的一致性”，保证通过redo log回放后的InnoDB数据与非InnoDB数据都是处于读锁期间取得的位点。

## 全备恢复 ##

全备恢复流程

1. 进入指定的备份目录,查看备份文件是否已经执行过apply-log .这在xtrabackup\_checkpoint文件中的backup\_type=full-backuped字段有记录,如果已经apply-log过的,该字段为:backup\_type=full-prepared

2. 在备份目录下读取xrabackup\_logfile文件,识别出文件大小和其实LSN号

3. 读取备份目录下的backup-my.cnf中的参数,为下一步的恢复过程启动一个mini innodb instance

4. 通过redolog的其实LSN号,往后扫描需要恢复的所有redolog

5. 备份文件执行apply-log的过程,被视同为非正常关闭的数据库之后的重启数据库,这个时候会对备份数据文件执行CrashRecivery

6. 应用redolog完成后,会执行一次正常关闭mini innodb instance操作

7. 重新启动mini innodb instance,使用backup-my.cnf配置文件中的redo log file配置生成新的redo log file重新启动mini innodb instance时又会重新执行一次crash recovery

8. 重新启动mini innodb instance正常之后,就执行正常的shutdown操作,完成apply-log过程

### 全备还原流程 ###

1.  模拟MySQL进行recover，将redo log回放到数据文件中
2.  等到recover完成
3.  重建redo log，为启动数据库做准备
4.  将数据文件复制回MySQL数据目录
5.  还原完成

### FAQ ###

在recover完成后，InnoDB数据与非InnoDB数据是达成一致的吗？

InnoDB数据会被恢复至备份结束时(全局读锁时)的状态，而非InnoDB数据本身即是在全局读锁时被复制出来，它们的数据一致

## 增量备份 ##

大部分流程跟全部相同，只有在步骤2 有所区别  
步骤2. 读取配置文件，找到相应的数据和日志文件的位置，读取上一次备份的`to_lsn`号作为增备的起始位置

### FAQ ###

1.  开始做一个增量备份, 那么 如何识别InnoDB的哪些数据是增量的?

数据文件中的数据页都有LSN号, **LSN可以看做是数据页的变更时间戳。** 通过这个时间戳, 就可以识别 数据页 在 全量备份后 是否修改过, 即**通过LSN可以识别数据是否是增量的**。

1.  如果一个数据页原本不是增量范围内的, 在增量备份的过程中, 数据页更新了, 那么增量备份是否会涵盖这个数据页?

本质, 与全量备份中的数据页新旧不一致的问题 相同, 解决方案也相同: 通过恢复时回放redo log, 解决数据新旧不一致的问题.  
也就是说: 增量备份过程中, 如果数据页被更新了, 那数据文件中的这个数据页\*\* 有可能 **被拷贝到备份中, 也可能 没有被拷贝到备份中, 但这个更新信息**一定会被redo log记录\*\*, 并被记录在备份中. 在恢复过程中, redo log会被"安全地"回放成功, 达成数据的新旧一致.

## 增备恢复 ##

增备恢复流程

1. 对全备执行appl-log+redo-only

1.1. 进入指定的备份目录,查看备份文件是否已经执行过apply-log .这在xtrabackup\_checkpoint文件中的backup\_type=full-backuped字段有记录,如果已经apply-log过的,该字段为:backup\_type=full-prepared

1.2. 在备份目录下读取xrabackup\_logfile文件,识别出文件大小和其实LSN号

1.3. 读取备份目录下的backup-my.cnf中的参数,为下一步的恢复过程启动一个mini innodb instance

1.4. 通过redolog的其实LSN号,往后扫描需要恢复的所有redolog

1.5. 备份文件执行apply-log的过程,被视同为非正常关闭的数据库之后的重启数据库,这个时候会对备份数据文件执行CrashRecivery

1.6. 应用redolog完成后,会执行一次正常关闭mini innodb instance操作 注:全备应用redolog时对未提交的事物不会执行回滚

2. 对增备执行apply-log+redo-only合并到全备中

2.1 进入指定备份目录,读取增备目录中的 xtabackup\_checkpoint 文件的from\_lsn字段的LSN值

2.2 查看xtabackup\_checkpoint文件中backup\_type字段是否为log-appled,如果是则表示全备目录已经执行过apply-log+redo-only

2.3 在备份目录下读取xtrabackup\_logfile文件,识别出文件大小和其实LSN号

2.4 读取备份目录下的backup-my.cnf中的参数,获取增备目录下的backup-my.cnf中的innodb\_log\_group\_home\_dir参数值

2.5 从增备目录下扫描所有innodb表增备的表空间文件:ibdata1/ibd,独立undolog并吧这些增量的表空间数据页应用到全备的对应表空间数据文件中

2.6 通过redolog的其实LSN号,往后扫描需要恢复的所有redolog

2.7 应用redolog完成之后,会执行一次正式关闭mini innodb instance操作 注:全备应用redolog时对未提交的事务不会执行回滚

2.8 从增备目录中复制.opt/.frm/.MYI/.MYD等非innodb引擎相关数据和表定义等文件,覆盖增备目录下,完成apply-log+redo-only操作

对全备执行apply-log

与全备流程图过程一样

### 增量备份流程总结 ###

1.  先还原一个全量备份 到 临时目录
2.  开始还原增量备份, 将增量备份中的增量的数据文件, 覆盖到临时目录中
3.  将增量备份中的redo log, 回放到临时目录中
4.  将其他文件覆盖到临时目录中
5.  增备还原完成
6.  重建redo log, 为启动数据库做准备
7.  将临时目录中的文件, 拷贝到MySQL的数据目录中

### FAQ ###

非事务类的信息, 能否产生增量备份？

非事务类的信息 没有提供识别增量的机制, 只能采用全局读锁+全部拷贝+全部回放的机制进行备份

参考链接  
[\[原理解析\] XtraBackup全量备份还原][XtraBackup]  
[\[原理解析\] XtraBackup增量备份还原][XtraBackup 1]  
[\[原理解析\] XtraBackup 备份恢复时为什么要加apply-log-only参数？  
][XtraBackup _apply-log-only_]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoZW4yMzA4_size_16_color_FFFFFF_t_70]

[XtraBackup]: https://mp.weixin.qq.com/s/G6X1pur3QY3Q8WsEdR5RYA
[XtraBackup 1]: https://mp.weixin.qq.com/s/C9znCtgRE0c7p-3fzFxspQ
[XtraBackup _apply-log-only_]: https://mp.weixin.qq.com/s/EVbXbYlTIVAT8r8PdLtBew
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoZW4yMzA4_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200215165407389.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoZW4yMzA4,size_16,color_FFFFFF,t_70