您好,登錄后才能下訂單哦!
這篇文章給大家介紹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的備份和恢復是怎么樣的就分享到這里了,希望以上內容可以對大家有一定的幫助,可以學到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。