Xtrabackup備份恢復原理
備份innodb表時，xtrabackup若干個線程拷貝獨立表空間的.ibd文件，并不停監視此過程中redo log的變化，添加到自己的事務日志文件（xtrabackup_logfile）中。在此過程中，發生的物理寫操作越多，xtrabackup_logfile越大。在拷貝完成后的第一個prepare階段，xtrabackup采用類似于innodb崩潰恢復的方法，把數據文件恢復到與日志文件一致的狀態，并把未提交的事務回滾。如果同時需要備份myisam表以及innodb表結構等文件，那么就需要用flush tables with lock來獲得全局鎖，開始拷貝這些不再變化的文件，同時獲得binlog位置，拷貝結束后釋放鎖，也停止對redo log的監視。
 
很多同學對上面的理解有混淆，以為拷貝.ibd文件就跟操作系統拷貝文件一樣。其實這里涉及到fractured page的問題，他應該會重新讀取（應該也有重試次數，超過后備份不成功）。
 
其實這個原理很簡單，了解下doublewrite就可以理解了“本段摘錄自《MySQL技術內幕：InnoDB存儲引擎》”：
如果說插入緩沖帶給InnoDB存儲引擎的是性能，那么兩次寫帶給InnoDB存儲引擎的是數據的可靠性。當數據庫宕機時，可能發生數據庫正在寫一個頁面，而這個頁只寫了一部分（比如16K的頁，只寫前4K的頁）的情況，我們稱之為部分寫失效（partial page write）。在InnoDB存儲引擎未使用double write技術前，曾出現過因為部分寫失效而導致數據丟失的情況。
 
有人也許會想，如果發生寫失效，可以通過重做日志進行恢復。這是一個辦法。但是必須清楚的是，重做日志中記錄的是對頁的物理操作，如偏移量800，寫“aaaa”記錄。如果這個頁本身已經損壞，再對其進行重做是沒有意義的。這就是說，在應用（apply）重做日志前，我們需要一個頁的副本，當寫入失效發生時，先通過頁的副本來還原該頁，再進行重做，這就是doublewrite。

一、下載和安裝
XtraBackup現在最新版本為2.1.5，官方也提供了2.0的版本可供下載，官方鏈接地址：http://www.percona.com/software/percona-xtrabackup；可以下載源碼編譯安裝，也可以下載適合的RPM包或使用yum進行安裝。由于沒有需要特殊定制的，因此建議直接使用RPM安裝即可。

安裝方法一：
下載RPM安裝包：

安裝依賴：

安裝：

發表評論 共有條評論 用戶名: 密碼: 驗證碼: 匿名發表