其中最主要的是 innobackupex 和 xtrabackup，前者是1個(gè) perl 腳本，后者是 C/C++ 編譯的2進(jìn)制。

xtrabackup 是用來(lái)備份 InnoDB 表的，不能備份非 InnoDB 表，和 mysqld server 沒(méi)有交互；innobackupex 腳本用來(lái)備份非 InnoDB 表，同時(shí)會(huì)調(diào)用 xtrabackup 命令來(lái)備份 InnoDB 表，還會(huì)和 mysqld server 發(fā)送命令進(jìn)行交互，如加讀鎖（FTWRL）、獲得位點(diǎn)（SHOW SLAVE STATUS）等。簡(jiǎn)單來(lái)講，innobackupex 在 xtrabackup 之上做了1層封裝。

1般情況下，我們是希望能備份 MyISAM 表的，雖然我們可能自己不用 MyISAM 表，但是 mysql 庫(kù)下的系統(tǒng)表是 MyISAM 的，因此備份基本都通過(guò) innobackupex 命令進(jìn)行；另外1個(gè)緣由是我們可能需要保存位點(diǎn)信息。

另外2個(gè)工具相對(duì)小眾些，xbcrypt 是加解密用的；xbstream 類似于tar，是 Percona 自己實(shí)現(xiàn)的1種支持并發(fā)寫(xiě)的流文件格式。兩都在備份和解壓時(shí)都會(huì)用到（如果備份用了加密和并發(fā)）。

本文的介紹的主角是 innobackupex 和 xtrabackup。

通訊方式

2個(gè)工具之間的交互和調(diào)和是通過(guò)控制文件的創(chuàng)建和刪除來(lái)實(shí)現(xiàn)的，主要文件有：

• xtrabackup_suspended_1
• xtrabackup_suspended_2
• xtrabackup_log_copied

舉個(gè)栗子，我們來(lái)看備份時(shí) xtrabackup_suspended_2 是怎樣來(lái)調(diào)和2個(gè)工具進(jìn)程的

1. innobackupex 在啟動(dòng) xtrabackup 進(jìn)程后，會(huì)1直等 xtrabackup 備份完 InnoDB 文件，方式就是等待 xtrabackup_suspended_2 這個(gè)文件被創(chuàng)建出來(lái)；
2. xtrabackup 在備完 InnoDB 數(shù)據(jù)后，就在指定目錄下創(chuàng)建出這個(gè)文件，然后等這個(gè)文件被 innobackupex 刪除；
3. innobackupex 檢測(cè)到文件 xtrabackup_suspended_2 被創(chuàng)建出來(lái)后，就繼續(xù)往下走；
4. innobackupex 在備份完非 InnoDB 表后，刪除 xtrabackup_suspended_2 這個(gè)文件，這樣就通知 xtrabackup可以繼續(xù)了，然后等 xtrabackup_log_copied 被創(chuàng)建；
5. xtrabackup 檢測(cè)到 xtrabackup_suspended_2 文件刪除后，就能夠繼續(xù)往下了。

是否是感覺(jué)有點(diǎn)不可思議，通過(guò)文件是不是存在來(lái)控制進(jìn)程，這類方式非常的不靠譜，由于非常容易被外部干擾，比如文件被他人誤刪掉，或2個(gè)正在跑的備份控制文件誤放在同1個(gè)目錄下，就等著備份亂掉吧，但是 Percona 就是這么干的。

之所以這么弄，估計(jì)主要是由于 perl 和 C 2進(jìn)制2個(gè)進(jìn)程，沒(méi)有既好用又方便的通訊方式，弄個(gè)協(xié)議啥的太麻煩了。但是官方也覺(jué)得這類方式不靠譜，11年就弄了個(gè) blueprint 要用C重寫(xiě) innobackupex，終究在2.3 版本實(shí)現(xiàn)了，innobackupex 功能全部集成到 xtrabackup 里面，只有1個(gè) binary，另外為了使用上的兼容斟酌，innobackupex作為 xtrabackup 的1個(gè)軟鏈。對(duì)2次開(kāi)發(fā)來(lái)講，2.3 擺脫了之前2個(gè)進(jìn)程協(xié)作的負(fù)擔(dān)，架構(gòu)上明顯要好過(guò)之前版本。斟酌到 perl + C 這類架構(gòu)的長(zhǎng)時(shí)間存在，大多數(shù)讀者朋友也基本用的2.3之前版本，本文的介紹也是基于老的架構(gòu)（2.2版本），但是原理和2.3是1樣的，只是實(shí)現(xiàn)上的差別。

備份進(jìn)程

全部備份進(jìn)程以下圖：

1. innobackupex 在啟動(dòng)后，會(huì)先 fork 1個(gè)進(jìn)程，啟動(dòng) xtrabackup進(jìn)程，然后就等待 xtrabackup 備份完 ibd 數(shù)據(jù)文件；
2. xtrabackup 在備份 InnoDB 相干數(shù)據(jù)時(shí)，是有2種線程的，1種是 redo 拷貝線程，負(fù)責(zé)拷貝 redo 文件，1種是 ibd 拷貝線程，負(fù)責(zé)拷貝 ibd 文件；redo 拷貝線程只有1個(gè)，在 ibd 拷貝線程之前啟動(dòng)，在 ibd 線程結(jié)束后結(jié)束。xtrabackup 進(jìn)程開(kāi)始履行后，先啟動(dòng) redo 拷貝線程，從最新的 checkpoint 點(diǎn)開(kāi)始順序拷貝 redo 日志；然后再啟動(dòng) ibd 數(shù)據(jù)拷貝線程，在 xtrabackup 拷貝 ibd 進(jìn)程中，innobackupex 進(jìn)程1直處于等待狀態(tài)（等待文件被創(chuàng)建）。
3. xtrabackup 拷貝完成idb后，通知 innobackupex（通過(guò)創(chuàng)建文件），同時(shí)自己進(jìn)入等待（redo 線程依然繼續(xù)拷貝）;
4. innobackupex 收到 xtrabackup 通知后，履行FLUSH TABLES WITH READ LOCK (FTWRL)，獲得1致性位點(diǎn)，然后開(kāi)始備份非 InnoDB 文件（包括 frm、MYD、MYI、CSV、opt、par等）。拷貝非 InnoDB 文件進(jìn)程中，由于數(shù)據(jù)庫(kù)處于全局只讀狀態(tài)，如果在業(yè)務(wù)的主庫(kù)備份的話，要特別謹(jǐn)慎，非 InnoDB 表（主要是MyISAM）比較多的話整庫(kù)只讀時(shí)間就會(huì)比較長(zhǎng)，這個(gè)影響1定要評(píng)估到。
5. 當(dāng) innobackupex 拷貝完所有非 InnoDB 表文件后，通知 xtrabackup（通過(guò)刪文件） ，同時(shí)自己進(jìn)入等待（等待另外一個(gè)文件被創(chuàng)建）；
6. xtrabackup 收到 innobackupex 備份完非 InnoDB 通知后，就停止 redo 拷貝線程，然后通知 innobackupexredo log 拷貝完成（通過(guò)創(chuàng)建文件）；
7. innobackupex 收到 redo 備份完成通知后，就開(kāi)始解鎖，履行 UNLOCK TABLES；
8. 最后 innobackupex 和 xtrabackup 進(jìn)程各自完成掃尾工作，如資源的釋放、寫(xiě)備份元數(shù)據(jù)信息等，innobackupex 等待 xtrabackup 子進(jìn)程結(jié)束后退出。

在上面描寫(xiě)的文件拷貝，都是備份進(jìn)程直接通過(guò)操作系統(tǒng)讀取數(shù)據(jù)文件的，只在履行 SQL 命令時(shí)和數(shù)據(jù)庫(kù)有交互，基本不影響數(shù)據(jù)庫(kù)的運(yùn)行，在備份非 InnoDB 時(shí)會(huì)有1段時(shí)間只讀（如果沒(méi)有MyISAM表的話，只讀時(shí)間在幾秒左右），在備份 InnoDB 數(shù)據(jù)文件時(shí)，對(duì)數(shù)據(jù)庫(kù)完全沒(méi)有影響，是真實(shí)的熱備。

InnoDB 和非 InnoDB 文件的備份都是通過(guò)拷貝文件來(lái)做的，但是實(shí)現(xiàn)的方式不同，前者是以page為粒度做的(xtrabackup)，后者是 cp 或 tar 命令(innobackupex)，xtrabackup 在讀取每一個(gè)page時(shí)會(huì)校驗(yàn) checksum 值，保證數(shù)據(jù)塊是1致的，而 innobackupex 在 cp MyISAM 文件時(shí)已做了flush（FTWRL），磁盤(pán)上的文件也是完全的，所以終究備份集里的數(shù)據(jù)文件都是寫(xiě)入完全的。

增量備份

PXB 是支持增量備份的，但是只能對(duì) InnoDB 做增量，InnoDB 每一個(gè) page 有個(gè) LSN 號(hào)，LSN 是全局遞增的，page 被更改時(shí)會(huì)記錄當(dāng)前的 LSN 號(hào)，page中的 LSN 越大，說(shuō)明當(dāng)前page越新（最近被更新）。每次備份會(huì)記錄當(dāng)前備份到的LSN（xtrabackup_checkpoints 文件中），增量備份就是只拷貝LSN大于上次備份的page，比上次備份小的跳過(guò)，每一個(gè) ibd 文件終究備份出來(lái)的是增量 delta 文件。

MyISAM 是沒(méi)有增量的機(jī)制的，每次增量備份都是全部拷貝的。

增量備份進(jìn)程和全量備份1樣，只是在 ibd 文件拷貝上有不同。

恢復(fù)進(jìn)程

如果看恢復(fù)備份集的日志，會(huì)發(fā)現(xiàn)和 mysqld 啟動(dòng)時(shí)非常相似，其實(shí)備份集的恢復(fù)就是類似 mysqld crash后，做1次 crash recover。

恢復(fù)的目的是把備份集中的數(shù)據(jù)恢復(fù)到1個(gè)1致性位點(diǎn)，所謂1致就是指原數(shù)據(jù)庫(kù)某1時(shí)間點(diǎn)各引擎數(shù)據(jù)的狀態(tài)，比如 MyISAM 中的數(shù)據(jù)對(duì)應(yīng)的是 15:00 時(shí)間點(diǎn)的，InnoDB 中的數(shù)據(jù)對(duì)應(yīng)的是 15:20 的，這類狀態(tài)的數(shù)據(jù)就是不1致的。PXB 備份集對(duì)應(yīng)的1致點(diǎn)，就是備份時(shí)FTWRL的時(shí)間點(diǎn)，恢復(fù)出來(lái)的數(shù)據(jù)，就對(duì)應(yīng)原數(shù)據(jù)庫(kù)FTWRL時(shí)的狀態(tài)。

由于備份時(shí) FTWRL 后，數(shù)據(jù)庫(kù)是處于只讀的，非 InnoDB 數(shù)據(jù)是在持有全局讀鎖情況下拷貝的，所以非 InnoDB 數(shù)據(jù)本身就對(duì)應(yīng) FTWRL 時(shí)間點(diǎn)；InnoDB 的 ibd 文件拷貝是在 FTWRL 前做的，拷貝出來(lái)的不同 ibd 文件最后更新時(shí)間點(diǎn)是不1樣的，這類狀態(tài)的 ibd 文件是不能直接用的，但是 redo log 是從備份開(kāi)始1直延續(xù)拷貝的，最后的 redo 日志點(diǎn)是在持有 FTWRL 后獲得的，所以終究通過(guò) redo 利用后的 ibd 數(shù)據(jù)時(shí)間點(diǎn)也是和 FTWRL 1致的。

所以恢復(fù)進(jìn)程只觸及 InnoDB 文件的恢復(fù)，非 InnoDB 數(shù)據(jù)是不動(dòng)的。備份恢復(fù)完成后，就能夠把數(shù)據(jù)文件拷貝到對(duì)應(yīng)的目錄，然后通過(guò)mysqld來(lái)啟動(dòng)了。