文章目录
前言
MySQL的备份是搞数据库的同学绕不过的话题。本文简要介绍了相关工具和原理。
xtrabackup
MacOS下面用brew命令安装
brew install percona-xtrabackup
其中xtrabackup2.4版本可以支持mysql5.7
软件包安装后一共有几个可执行文件：
- 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 命令进行；另外一个原因是我们可能需要保存位点信息。
另外2个工具相对小众些，xbcrypt 是加解密用的；xbstream 类似于tar，使用它还需要依赖qpress是 Percona 自己实现的一种支持并发写的流文件格式。两都在备份和解压时都会用到（如果备份用了加密和并发）。
原理
通信方式
2个工具之间的交互和协调是通过控制文件的创建和删除来实现的，主要文件有：
xtrabackup_suspended_1
xtrabackup_suspended_2
xtrabackup_log_copied
举个例子，我们来看备份时 xtrabackup_suspended_2 是怎么来协调2个工具进程的
- innobackupex 在启动 xtrabackup 进程后，会一直等 xtrabackup 备份完 InnoDB 文件，方式就是等待 xtrabackup_suspended_2 这个文件被创建出来；
- xtrabackup 在备完 InnoDB 数据后，就在指定目录下创建出这个文件，然后等这个文件被 innobackupex 删除；
- innobackupex 检测到文件 xtrabackup_suspended_2 被创建出来后，就继续往下走；
- innobackupex 在备份完非 InnoDB 表后，删除 xtrabackup_suspended_2 这个文件，这样就通知 xtrabackup 可以继续了，然后等 xtrabackup_log_copied 被创建；
- xtrabackup 检测到 xtrabackup_suspended_2 文件删除后，就可以继续往下了。
是不是感觉有点不可思议，通过文件是否存在来控制进程，这种方式非常的不靠谱，因为非常容易被外部干扰，比如文件被别人误删掉，或者2个正在跑的备份控制文件误放在同一个目录下，就等着备份乱掉吧，但是 Percona 就是这么干的。
备份过程
- innobackupex 在启动后，会先 fork 一个进程，启动 xtrabackup进程，然后就等待 xtrabackup 备份完 ibd 数据文件；
- xtrabackup 在备份 InnoDB 相关数据时，是有2种线程的，1种是 redo 拷贝线程，负责拷贝 redo 文件，1种是 ibd 拷贝线程，负责拷贝 ibd 文件；redo 拷贝线程只有一个，在 ibd 拷贝线程之前启动，在 ibd 线程结束后结束。xtrabackup 进程开始执行后，先启动 redo 拷贝线程，从最新的 checkpoint 点开始顺序拷贝 redo 日志；然后再启动 ibd 数据拷贝线程，在 xtrabackup 拷贝 ibd 过程中，innobackupex 进程一直处于等待状态（等待文件被创建）。
- xtrabackup 拷贝完成ibd后，通知 innobackupex（通过创建文件），同时自己进入等待（redo 线程仍然继续拷贝）;
- innobackupex 收到 xtrabackup 通知后，执行FLUSH TABLES WITH READ LOCK (FTWRL)，取得一致性位点，然后开始备份非 InnoDB 文件（包括 frm、MYD、MYI、CSV、opt、par等）。拷贝非 InnoDB 文件过程中，因为数据库处于全局只读状态，如果在业务的主库备份的话，要特别小心，非 InnoDB 表（主要是MyISAM）比较多的话整库只读时间就会比较长，这个影响一定要评估到。
- 当 innobackupex 拷贝完所有非 InnoDB 表文件后，通知 xtrabackup（通过删文件） ，同时自己进入等待（等待另一个文件被创建）；
- xtrabackup 收到 innobackupex 备份完非 InnoDB 通知后，就停止 redo 拷贝线程，然后通知 innobackupex redo log 拷贝完成（通过创建文件）；
- innobackupex 收到 redo 备份完成通知后，就开始解锁，执行 UNLOCK TABLES；
- 最后 innobackupex 和 xtrabackup 进程各自完成收尾工作，如资源的释放、写备份元数据信息等，innobackupex 等待 xtrabackup 子进程结束后退出。
在上面描述的文件拷贝，都是备份进程直接通过操作系统读取数据文件的，只在执行 SQL 命令时和数据库有交互，基本不影响数据库的运行，在备份非 InnoDB 时会有一段时间只读（如果没有MyISAM表的话，只读时间在几秒左右），在备份 InnoDB 数据文件时，对数据库完全没有影响，是真正的热备。
InnoDB 和非 InnoDB 文件的备份都是通过拷贝文件来做的，但是实现的方式不同，前者是以page为粒度做的(xtrabackup)，后者是 cp 或者 tar 命令(innobackupex)，xtrabackup 在读取每个page时会校验 checksum 值，保证数据块是一致的，而 innobackupex 在 cp MyISAM 文件时已经做了flush（FTWRL），磁盘上的文件也是完整的，所以最终备份集里的数据文件都是写入完整的。
增量备份
1 PXB 是支持增量备份的，但是只能对 InnoDB 做增量，InnoDB 每个 page 有个 LSN 号，LSN 是全局递增的，page 被更改时会记录当前的 LSN 号，page中的 LSN 越大，说明当前page越新（最近被更新）。每次备份会记录当前备份到的LSN（xtrabackup_checkpoints 文件中），增量备份就是只拷贝LSN大于上次备份的page，比上次备份小的跳过，每个 ibd 文件最终备份出来的是增量 delta 文件。
2 MyISAM 是没有增量的机制的，每次增量备份都是全部拷贝的。
3 增量备份过程和全量备份一样，只是在 ibd 文件拷贝上有不同。
恢复过程
backup的恢复过程中包括恢复和还原两个部分。
我们前面已经说了xtrabackup只备份InnoDB表的ibd文件，而innobackupex可以备份包括InnoDB表在内的其他存储引擎的表的所有数据文件。由于不同引擎表备份时的不同，也会让恢复过程看起来不一样。
先来看看完全备份集的恢复。
- 在InnoDB表的备份或者更直接的说ibd数据文件复制的过程中，数据库处于不一致的状态，所以要将xtraback_logfile中尚未提交的事务进行回滚，以及将已经提交的事务进行前滚，
使各个数据文件处于一个一致性状态，这个过程叫做“准备(prepare)”。 - 如果你是在一个从库上执行的备份，那说明你没有东西需要回滚，只是简单的apply redo log就可以了。另外在prepare过程中可以使用参数–use-memory增大使用系统内存量从而提高恢复速度。
- 之后，我们就可以根据backup-my.cnf中的配置把数据文件复制回对应的目录了，当然你也可以自己复制回去，但innobackupex都会帮我们完成。在这里，对于InnoDB表来说是完成“后准备”动作，我们称之为“恢复(recovery)”，而对于MyISAM表来说由于备份时是采用锁表方式复制的，所以此时只是简单的复制回来，不需要apply log，这个我们称之为“还原(restore)”。
注：本文档里之所以使用恢复和还原，也是和其他数据库比如Oracle看起来一样。
对于增量备份的恢复过程，与完全备份集的恢复类似，只是有少许不同：
- 恢复过程需要使用完全备份集和各个增量备份集，各个备份集的恢复与前面说的一样（前滚和回滚），之后各个增量备份集的redo log都会应用到完全备份集中；
- 对于完全备机集之后产生的新表，要有特殊处理方式，以便恢复后不丢表；
- 要以完全备份集为基础，然后按顺序应用各个增量备份集。
最后可以看看不同备份策略
innobackupex
innobackupex是percona提供的一个使用perl语言完成的脚本工具。此工具调用xtrabackup和tar4ibd工具，实现很多对性能要求并不高的任务和备份逻辑。
接下来将介绍innobackupex备份和恢复的实现原理。
备份
如果在程序启动阶段未指定模式，innobackupex将会默认以备份模式启动。
默认情况下，此脚本以–suspend-at-end选项启动xtrabackup，然后xtrabackup程序开始拷贝InnoDB数据文件。当xtrabackup程序执行结束，innobackupex将会发现xtrabackup创建了xtrabackup_suspended_2文件，然后执行FLUSH TABLES WITH READ LOCK，此语句对所有的数据库表加读锁。然后开始拷贝其他类型的文件。
如果–ibbackup未指定，innobackupex将会自行尝试确定使用的xtrabackup的binary。其确定binary的逻辑如下：首先判断备份目录中xtrabackup_binary文件是否存在，如果存在，此脚本将会依据此文件确定使用的xtrabackup binary。否则，脚本将会尝试连接database server，通过server版本确定binary。如果连接无法建立，xtrabackup将会失败，需要自行指定binary文件。
在binary被确定后，将会检查到数据库server的连接是否可以建立。其执行逻辑是：建立连接、执行query、关闭连接。若一切正常，xtrabackup将以子进程的方式启动。
FLUSH TABLES WITH READ LOCK是为了备份MyISAM和其他非InnoDB类型的表，此语句在xtrabackup已经备份InnoDB数据和日志文件后执行。在这之后，将会备份 .frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSM, .CSV, .par, and .opt 类型的文件。
当所有上述文件备份完成后，innobackupex脚本将会恢复xtrabackup的执行，等待其备份上述逻辑执行过程中生成的事务日志文件。接下来，表被解锁，slave被启动，到server的连接被关闭。接下来，脚本会删掉xtrabackup_suspended_2文件，允许xtrabackup进程退出。
恢复
为了恢复一个备份，innobackupex需要以–copy-back选项启动。
innobackupex将会首先通过my.cnf文件读取如下变量：datadir, innodb_data_home_dir, innodb_data_file_path, innodb_log_group_home_dir，并确定这些目录存在。
接下来，此脚本将会首先拷贝MyISAM表、索引文件、其他类型的文件（如：.frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSM, .CSV, par and .opt files），接下来拷贝InnoDB表数据文件，最后拷贝日志文件。拷贝执行时将会保留文件属性，在使用备份文件启动MySQL前，可能需要更改文件的owener（如从拷贝文件的user更改到mysql用户）。