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/