Xtrabackup备份原理

xtrabackup的备份原理

• 软件包安装完成以后一共有4个可执行文件，以下:

usr
├── bin
│   ├── innobackupex
│   ├── xbcrypt
│   ├── xbstream
│   └── xtrabackup

其中最主要的是innobackupex和xtrabackup，前者是一个perl脚本，后者是C/C++编译的二进制。

• xtrabackup是用来备份InnoDB表的，不能备份非InnoDB表，和mysqld server没有交互；innobackupex脚本用来备份非InnoDB表，同时会调用xtrabackup命令备份InnoDB表，还会和mysqld server发送命令进行交互，如加读锁(FTWRL)，获取位点(SHOW SLAVE STATUS)等。简单来讲，innobackupex在xtrabackup之上作了一层封装。
• 通常状况下咱们是但愿备份MyISAM表的，虽然咱们可能本身不用MyISAM表，可是mysql库下面的系统表示MyISAM的，所以备份基本都经过innobackupex命令进行；另一个缘由是咱们可能须要保存位点信息。
• 另外俩个工具比较小众一些，xbcrypt是加解密用的；`xbstream相似于tar，是Percona本身实现的一种支持并发写的流文件格式。俩者都在备份和解压的时候都会用到(若是备份用到了加密和并发)。

原理

通讯方式

2个工具之间的交互和协调是经过控制文件的建立和删除来实现的，主要文件有：

• xtrabackup_suspended_1
• xtrabackup_suspended_2
• xtrabackup_log_copied

1. innobackupex在启动xtrabackup进程后，会一直等待xtrabackup备份完InnoDB文件，方式就是等待xtrabackup_suspended_2这个文件被建立出来；
2. xtrabackup在备份完InnoDB数据后，就在指定的目录下建立出xtrabackup_suspended_2这个文件，而后等待innobackupex删除；
3. innobackupex检测到文件xtrabackup_suspended_2被建立出来以后，就继续往下走；
4. innobackupex备份完非InnoDB表后，删除xtrabackup_suspended_2这个文件，这样就通知xtrabackup能够继续了，而后等xtrabackup_log_copied被建立；
5. xtrabackup检测到xtrabackup_suspended_2文件删除以后，就能够继续下去了。

经过文件是否存在来控制进程这种方式是很是的不靠谱的，由于很是容易被外部干扰，好比文件被其余人误删除掉，活着2个正在跑的备份控制文件误放在同一个目录下面，那么备份很容易乱掉的。

之因此这么作的缘由是由于perl和C二进制2个进程，没有既好用又方便的通讯方式，弄个协议的话又太麻烦了，因此才会出现这种方式进行通讯。

可是官方在2.3版本实现了将innobackupex功能所有集成到了xtrabackup，只有一个binary，另外为了使用上的兼容考虑，innobackupex做为xtrabackup的一个软链。对于二次开发来讲，2.3摆脱了以前2个进程协做的负担，架构上明显要好于以前的版本。

2.3以前版本innobackupex备份流程

1. innobackupex在启动后，会先fork一个进程，启动xtrabackup进程，而后等待xtrabackup备份完ibd数据文件；
2. xtrabackup在备份InnoDB相关数据时候，是有2种线程的，1种是redo拷贝线程，负责拷贝redo文件，1种是ibd拷贝线程，负责拷贝ibd文件；redo拷贝线程只有一个，在ibd拷贝线程以前启动，在ibd线程结束后结束。xtrabackup进程开始执行后，先启动redo拷贝线程，从最新的checkpoint点开始顺序拷贝redo日志；而后再启动ibd数据拷贝线程，在xtrabackup拷贝ibd过程当中，innobackupex进程一直处于等待状态(等待文件被建立)；
3. xtrabackup拷贝完成ibd后，通知innobackupex（经过建立文件），同时本身进入等待(redo拷贝线程任然继续拷贝)；
4. innobackupex受到xtrabackup通知后，执行FLUSH TABLES WITH READ LOCK(FTWRL)，取得一致性位点，而后开始备份非InnoDB文件(包括frm,MYD,CSV,opt,par等)。拷贝非InnoDB文件过程当中，由于数据库属于全局只读状态，若是在业务的主库备份的话，须要特别当心，非InnoDB（主要是MyISAM）比较多的话那么整个只读的时间就会比较长，这个影响须要评估到；
5. 当innobackupex拷贝完全部的非InnoDB表文件以后，通知xtrabackup(经过删除文件)，同时本身进入等待(等待另外一个文件被建立)
6. xtrabackup收到innobackupex备份完非InnoDB通知后，就中止redo拷贝线程，而后通知innobackupexredo log拷贝完成（经过建立文件）；
7. innobackupex收到redo备份完成通知后，就开始解锁，执行UNLOCK TABLES;；
8. 最后innobackupex和xtrabackup进程各自完成收尾工做，如资源的释放，写备份元数据信息等，innobackupex和xtrabackup子进程结束后退出。

在上面描述的文件拷贝，都是备份进程直接经过操做系统读取数据文件的，只在执行SQL命令时和数据库又交互，基本不影响数据库的运行，在备份非InnoDB时会有一段时间的只读(若是没有MyISAM表的话，只读时间在几秒左右)，在备份InnoDB数据文件时，对数据库彻底没有影响，是真正的热备。

InnoDB和非InnoDB文件的备份都是经过拷贝文件来作的，可是实现方式不一样，前者是以page为粒度作的（xtrabackup），后者是cp或者tar命令(innobackupex)，xtrabackup在读取每一个page时会校验checksum值，保证数据块是一致的，而innobackupex在cp MyISAM文件时已经作了flush(FTWRL)，磁盘上的文件也是完整的，因此最终备份集里的数据文件都是写入完整的。

增量备份

PXB是支持增量备份的，可是只能对InnoDB作增量，InnoDB每一个page有个LSN号，LSN是全局递增的，page被更改时会记录当前的LSN号，page中LSN越大，说明当前的page越新(最近被更新)。每次备份会记录到当前备份到的LSN（xtrabackup_checkpoints文件中）,增量别发就是只拷贝LSN大于上次备份的page，比上次备份小的跳过，每一个ibd文件最终出来的是增量delta文件。

MyISAM是没有增量机制的，每次增量备份都是所有拷贝的。

增量备份过程和全量备份同样，只是和ibd文件拷贝不同。

恢复过程

如何看恢复备份集的日志，会发现和mysqld启动时很是类似，其实备份集的恢复就是相似mysqld crash后，作一次crash recover。

恢复的目的就是把备份集中的数据恢复到一个一致性位点，所谓的一致就是指原数据库某一时间点各引擎数据的状态，好比MyISAM中的数据对应的是15:00时间点的，InnoDB中的数据对应的是15:20的，这种状态的数据就是不一致的。PXB备份集对应的一致点，就是备份FTWRL的时间点，恢复出来的数据，就是对应原数据库FTWRL时的状态。

由于备份时FTWRL后，数据库时处于只读的，非InnoDB数据是在持有全局读锁状况下拷贝的，因此非InnoDB数据自己就对应FTWRL时间点；InnoDB的ibd文件拷贝时在FTWRL前作的，拷贝出来的不一样的ibd文件最后更新点是不同的，这种状态的ibd文件是不能直接用的，可是redo log是从备份开始一直持续拷贝的，最后的redo日志点事在持有FTWRL后取得的，因此最终经过redo应用后的ibd数据时间点也是和FTWRL一致的。

因此恢复过程只是涉及InnoDB文件的恢复，非InnoDB数据事不动的。备份恢复完成以后，就能够把数据文件拷贝到对应的目录，而后就能够经过mysqld来启动了。

转载

http://mysql.taobao.org/monthly/2016/03/07/