现在有个需求需要对使用 innodb 的数据库进行热备。网上查了很多工具皆推荐 Percona-xtrabackup 于是就仔细了解调研一番。
我们可以前往 https://www.percona.com/downloads/XtraBackup/LATEST/ 下载我们需要的 linux 发行版的对应版本。 这里我下载了最近的稳定版本 2.4.12 rpm 包。
使用 tar -zvf 解压后 得到了好几个 rpm 文件。 安装了 percona-xtrabackup-24-2.4.12-1.el7.x86_64.rpm 并且提示需要下载 libev-4.24-7.fc29.x86_64.rpm 。
https://fedora.pkgs.org/rawhide/fedora-x86_64/libev-4.24-7.fc29.x86_64.rpm.html 下载对应包。
安装了通用版本的 libev-4.24-7.fc29.x86_64.rpm 包之后就算成功安装完成啦！
当我们安装完成之后运行目录如下：
usr
├── bin
│ ├── innobackupex
│ ├── xbcrypt
│ ├── xbstream
│ └── xtrabackup
有四个工具可以给我们直接调用。其中最主要的是 innobackupex 和 xtrabackup，前者是一个 perl 脚本，后者是 C/C++ 编译的二进制。
下面内容来引用于 rds 内核组文章，由于写得很好原理也很清晰所以直接贴过来做 backup 了。
其中最主要的是
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，是 Percona 自己实现的一种支持并发写的流文件格式。两都在备份和解压时都会用到（如果备份用了加密和并发）。本文的介绍的主角是
innobackupex和xtrabackup。原理
通信方式
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 就是这么干的。
之所以这么搞，估计主要是因为 perl 和 C 二进制2个进程，没有既好用又方便的通信方式，搞个协议啥的太麻烦了。但是官方也觉得这种方式不靠谱，11年就搞了个 blueprint 要用C重写
innobackupex，终于在2.3 版本实现了，innobackupex功能全部集成到xtrabackup里面，只有一个 binary，另外为了使用上的兼容考虑，innobackupex作为xtrabackup的一个软链。对于二次开发来说，2.3 摆脱了之前2个进程协作的负担，架构上明显要好于之前版本。考虑到 perl + C 这种架构的长期存在，大多数读者朋友也基本用的2.3之前版本，本文的介绍也是基于老的架构（2.2版本），但是原理和2.3是一样的，只是实现上的差别。
可以看到在 2.3 之前的版本，都是通过对文件的生成的监控来控制整个备份流程的。
Reference:
http://mysql.taobao.org/monthly/2016/03/07/ 阿里云 rds 内核组 Percona-xtrabackup 文章
https://www.percona.com/doc/percona-xtrabackup/2.4/backup_scenarios/full_backup.html full backup 官方文档
https://www.aliyun.com/jiaocheng/1106116.html Percona XtraBackup 备份和还原数据库
http://www.ttlsa.com/mysql/the-database-part-of-backup-using-percona-xtrabackup/ 使用Percona Xtrabackup对数据库进行部分备份