xtraBackup備份原理剖析

xtrabackup做爲innodb的hotbackup工具，由percona公司開發，因開源，熱備份和物理備份而
在mysql中部署普遍，詳情的說明可見以前的博客討論.

  在物理級別熱備份主要的一大挑戰就是在文件級別數據塊不一致.咱們知道innodb的單個page大小
由innodb_page_size 來決定，通常爲16K.由4個文件系統4K的塊組成.

mysql> show global variables like 'innodb_page_size';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| innodb_page_size | 16384 | 
+------------------+-------+
1 row in set (0.00 sec)

  
   因爲是熱備份，當備份工具在拷貝innodb page的時候，數據庫自己的進程也有可能在寫這個page
那麼備份工具拷貝出來的page,就有多是壞的,也稱爲page 頭尾不一致或是page斷裂.這也就是爲何
普通的os複製工具不能用來作爲數據庫物理熱備份的工具緣由.

    再看來看xtrbackup工具是怎麼解決這一問題的.在備份開始的時候，xtrabackup會像普通的拷貝工具同樣
去複製全部的innodb page,因此也會有page斷裂的問題存在。xtrabackup在備份開始的時候，生成另
一個線程去拷貝當前的innodb的事務日誌, 並同時監控innodb的事務日誌文件,一旦有生成新的innodb的事務日誌，
也會同時寫到xtrabckup本身的日誌中去.

     在備份結束後，xtrabacup獲得的結果是一份有page斷裂的數據文件和備份期間全部的innodb的事務日誌.這個
時候的狀況和mysql實例崩潰的結果是同樣的(實例崩潰後數據文件不完整，事務日誌完整).xtrabackup還須要一
個過程，稱爲prepare,這個過程所作的事情和mysql實例崩潰後所作的操做基本一致。利用壞的數據文件和事務
日誌進行rollback和forward操做。

      xtrabckup自己連接了innodb相關的庫,所在咱們在prepare階段看到innodb的啓動和關閉信息，很相似於標
準的mysql實例啓動和關閉過程，實質是咱們在prepare的時候，xtrabackup在調用innodb相關的代碼進行實例
恢復.prepare事後，xtrabackup備份文件就是一個一致性的數據拷貝，能夠直接用來啓動mysql。

   能夠看到xtrabackup經過innodb的事務日誌來和數據page,進行實例恢復，而後獲得一致性的備份.而對於那些
非innodb的表則無能爲力了，由於沒有事務日誌.因此咱們能夠看到在xtrackup備份Myisam的表，仍是須要只讀表
鎖來進行鎖定，而後再備份數據文件,和普通的拷貝工具無異.