轉載:MySQL · 物理備份 · Percona XtraBackup 備份原理
前言
Percona XtraBackup（簡稱PXB）是 Percona 公司開發的一個用于 MySQL 數據庫物理熱備的備份工具，支持 MySQl（Oracle）、Percona Server 和 MariaDB，并且全部開源，真可謂是業界良心。我們 RDS MySQL 的物理備份就是基于這個工具做的。
項目的 blueprint 和 bug 討論放在?Launchpad，代碼之前也放在 Launchpad，現在已經遷移到?Github?啦，項目更新發布非常快，感興趣的可以關注 :-)
本文會介紹下備份工具的工作原理，希望對大家有所幫助。
工具集
軟件包安裝完后一共有4個可執行文件，如下：
其中最主要的是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是一樣的，只是實現上的差別。
備份過程
整個備份過程如下圖：
PXB 備份過程
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拷貝完成idb后，通知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 拷貝線程，然后通知innobackupexredo 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），磁盤上的文件也是完整的，所以最終備份集里的數據文件都是寫入完整的。
增量備份
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/
如有侵權或不周之處，敬請勞煩聯系若飛（微信：1321113940）馬上刪除，謝謝！
·END·
