共計 1602 個字符，預計需要花費 5 分鐘才能閱讀完成。

這篇文章給大家介紹 innobackupex 的備份和恢復是怎么樣的，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

原理

階段：備份 backup – 預恢復 prepare  — 恢復 restore

表文件時可能包含不完整事務，需要 prepare 將其變為 consistent 數據文件，這樣復制出來的文件肯定是不一致的，然后對每個文件進行崩潰恢復處理，最終達到一致.

在啟動的時候會記錄一個 LSN（log sequence number），然后就把所有的 Innodb 數據文件復制出來，這樣復制出來的數據文件是不一致的，但是 XtraBackup 會在后臺運行一個進程把所有對 redo
log file 的修改記錄下來；

二進制程序（比如 xtrabackup_55）完成的，如果使用 innobackupex 腳本，剛才的步驟完成以后，innobackupex 就會去備份 MyISAM 表和.frm 文件，這時要保證數據的一致性就會先鎖表了，通過 FLUSH
TABLES WITH READ LOCK 命令鎖表然后把文件復制出來，再釋放掉這個鎖。

（recovery）和 restore 兩個步驟。在 prepare 結束以后，Innodb 的表恢復到了復制 Innodb 文件結束的時間點，這個時間點也就是鎖表復制 MyISAM 表的起點，所以最終數據是一致的。一般我們在恢復的時候執行兩次 prepare，是因為第二次 prepare 會幫助我們生成 redo log 文件，從而加快 MySQL 數據庫啟動的速度。

將數據庫備份放在 BACKUP-DIR 目錄，默認新建一個子目錄，–no-timestamp 會跳過此功能；選項指定所用內存以加快進度，默認 100M；讀取 datadir/innodb_data_home_dir/innodb_data_file_path 等變量；

表是 innodb 表，最后為 logfile；–data-dir 目錄必須為空

增量備份文件，內容如下

文件內容如下

有點復雜，如果對 base
backup 執行事務一致性恢復，則其不能再用于增量備份恢復，為此須指定—redo-only 選項；

恢復單表提供了 restore datafile，針對壞塊也有 blockrecover，即盡可能的避免全庫恢復；也提供了類似功能，允許恢復單個表空間；讓 innodb 采用 slow shutdown(full purge +
change buffer merge)，以保證表空間處于一致性并被 import；

數據字典的 dump，5.6 起不是必需；

創建相同結構的表復制到數據目錄

基于時間點的恢復，記錄備份 binlog 時數據庫當前位置，這也是數據庫一致性恢復的終點；

執行時間點恢復

–start-position=57
–stop-datetime= 11-12-25 01:00:00 | mysql -u root –p

在 slave 執行備份

須留意以下兩個參數

– 從屬信息

此選項在備份復制從屬服務器時非常有用。它打印主服務器的二進制日志位置和名稱。它還將此信息作為更改主命令寫入 xtrabackup_slave_info 文件。通過在此備份上啟動從屬服務器，并使用保存在 xtrabackup\u slave\u info 文件中的二進制日志位置發出 CHANGE master 命令，可以設置此主服務器的新從屬服務器。

– 安全從備份

停止從屬 SQL 線程并等待啟動備份，直到“顯示”狀態下的從屬打開臨時表為零。如果沒有打開的臨時表，將進行備份，否則將啟動和停止 SQL 線程，直到沒有打開的臨時表。如果在 –safe Slave backup timeout 秒后 Slave_open_temp_tables 未變為零，備份將失敗。備份完成后，從屬 SQL 線程將重新啟動。

關于 innobackupex 的備份和恢復是怎么樣的就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。