備份原理:
XtraBackup基于InnoDB的crash-recovery功能。它會復制innodb的data file，由于不鎖表，復制出來的數據是不一致的，在恢復的時候使用crash-recovery，使得數據恢復一致。
InnoDB維護了一個redo log，又稱為transaction log，事務日志，它包含了innodb數據的所有改動情況。當InnoDB啟動的時候，它會先去檢查data file和transaction log，并且會做二步操作：
XtraBackup在備份的時候， 一頁一頁地復制innodb的數據，而且不鎖定表，與此同時，XtraBackup還有另外一個線程監(jiān)視著transactions log，一旦log發(fā)生變化，就把變化過的log pages復制走。
為什么要急著復制走呢？ 因為transactions log文件大小有限，寫滿之后，就會從頭再開始寫，所以新數據可能會覆蓋到舊的數據。
在prepare過程中，XtraBackup使用復制到的transactions log對備份出來的innodb data file進行crash recovery。
官方原理:
在InnoDB內部會維護一個redo日志文件，我們也可以叫做事務日志文件。事務日志會存儲每一個InnoDB表數據的記錄修改。當InnoDB啟動時，InnoDB會檢查數據文件和事務日志，
并執(zhí)行兩個步驟：它應用（前滾）已經提交的事務日志到數據文件，并將修改過但沒有提交的數據進行回滾操作。
xtrabackup在啟動時會記住log sequence number（LSN），并且復制所有的數據文件。復制過程需要一些時間，所以這期間如果數據文件有改動，那么將會使數據庫處于一個不同
的時間點。這時，xtrabackup會運行一個后臺進程，用于監(jiān)視事務日志，并從事務日志復制最新的修改。
xtrabackup必須持續(xù)的做這個操作，是因為事務日志是會輪轉重復的寫入，并且事務日志可以被重用。所以xtrabackup自啟動開始，就不停的將事務日志中每個數據文件的修改都記錄下來。
上面就是xtrabackup的備份過程。接下來是準備（prepare）過程。在這個過程中，xtrabackup使用之前復制的事務日志，對各個數據文件執(zhí)行災難恢復（就像MySQL剛啟動時要做的一樣）。
當這個過程結束后，數據庫就可以做恢復還原了。
以上的過程在xtrabackup的編譯二進制程序中實現。程序innobackupex可以允許我們備份MyISAM表和frm文件從而增加了便捷和功能。Innobackupex會啟動xtrabackup，直到xtrabackup復制
數據文件后，然后執(zhí)行FLUSH TABLES WITH READ LOCK來阻止新的寫入進來并把MyISAM表數據刷到硬盤上，之后復制MyISAM數據文件，最后釋放鎖。
備份MyISAM和InnoDB表最終會處于一致，在準備（prepare）過程結束后，InnoDB表數據已經前滾到整個備份結束的點，而不是回滾到xtrabackup剛開始時的點。這個時間點與執(zhí)行FLUSH TABLES WITH READ LOCK
的時間點相同，所以MyISAM表數據與InnoDB表數據是同步的。類似Oracle的，InnoDB的prepare過程可以稱為recover（恢復），
MyISAM的數據復制過程可以稱為restore（還原）。
xtrabackup和innobackupex這兩個工具都提供了許多前文沒有提到的功能特點。手冊上有對各個功能都有詳細的介紹。簡單介紹下，這些工具提供了如流（streaming）備份，增量（incremental）備份等，
通過復制數據文件，復制日志文件和提交日志到數據文件（前滾）實現了各種復合備份方式。

分享標題：MySQLXtrabackup備份原理和實現細節(jié)-創(chuàng)新互聯
瀏覽路徑：http://aaarwkj.com/article40/jdceo.html

成都網站建設公司_創(chuàng)新互聯，為您提供服務器托管、網站導航、網站維護、品牌網站設計、網站營銷、微信公眾號

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯