MySQL Xtrabackup備份原理和實現細節

備份原理:
XtraBackup基於InnoDB的crash-recovery功能。它會複製innodb的data file，由於不鎖表，複製出來的資料是不一致的，在恢復的時候使用crash-recovery，使得資料恢復一致。 
InnoDB維護了一個redo log，又稱為transaction log，事務日誌，它包含了innodb資料的所有改動情況。當InnoDB啟動的時候，它會先去檢查data file和transaction log，並且會做二步操作： 
XtraBackup在備份的時候， 一頁一頁地複製innodb的資料，而且不鎖定表，與此同時，XtraBackup還有另外一個執行緒監視著transactions log，一旦log發生變化，就把變化過的log pages複製走。
為什麼要急著複製走呢？ 因為transactions log檔案大小有限，寫滿之後，就會從頭再開始寫，所以新資料可能會覆蓋到舊的資料。 
在prepare過程中，XtraBackup使用複製到的transactions log對備份出來的innodb data file進行crash recovery。 

官方原理:
在InnoDB內部會維護一個redo日誌檔案，我們也可以叫做事務日誌檔案。事務日誌會儲存每一個InnoDB表資料的記錄修改。當InnoDB啟動時，InnoDB會檢查資料檔案和事務日誌，
並執行兩個步驟：它應用（前滾）已經提交的事務日誌到資料檔案，並將修改過但沒有提交的資料進行回滾操作。
xtrabackup在啟動時會記住log sequence number（LSN），並且複製所有的資料檔案。複製過程需要一些時間，所以這期間如果資料檔案有改動，那麼將會使資料庫處於一個不同
的時間點。這時，xtrabackup會執行一個後臺程式，用於監視事務日誌，並從事務日誌複製最新的修改。
xtrabackup必須持續的做這個操作，是因為事務日誌是會輪轉重複的寫入，並且事務日誌可以被重用。所以xtrabackup自啟動開始，就不停的將事務日誌中每個資料檔案的修改都記錄下來。

實現細節:
　　XtraBackup以read-write模式開啟innodb的資料檔案，然後對其進行復制。其實它不會修改此檔案。也就是說，執行 XtraBackup的使用者，必須對innodb的資料檔案具有讀寫許可權。
之所以採用read-write模式是因為XtraBackup採用了其內建的 innodb庫來開啟檔案，而innodb庫開啟檔案的時候就是rw的。
　　XtraBackup要從檔案系統中複製大量的資料，所以它儘可能地使用posix_fadvise()，來告訴OS不要快取讀取到的資料，從 而提升效能。因為這些資料不會重用到了，OS卻沒有這麼聰明。
如果要快取一下的話，幾個G的資料，會對OS的虛擬記憶體造成很大的壓力，其它程式，比如 mysqld很有可能被swap出去，這樣系統就會受到很大影響了。 
　　在備份innodb page的過程中，XtraBackup每次讀寫1MB的資料，1MB/16KB=64個page。這個不可配置。讀1MB資料之後，XtraBackup一頁一頁地遍歷這1MB資料，使用innodb的buf_page_is_corrupted()
函式檢查此頁的資料是否正常， 如果資料不正常，就重新讀取這一頁，最多重新讀取10次，如果還是失敗，備份就失敗了，退出。在複製transactions log的時候，每次讀寫512KB的資料。
同樣不可以配置。