1. 程式人生 > >xtrabackup備份原理

xtrabackup備份原理

原理 oba mydumper poi term 讀取 等待 庫文件 isa

物理備份(Xtrabackup)

相對於邏輯備份利用查詢提取數據中的所有記錄,物理備份更直接,拷貝數據庫文件和日誌來完成備份,因此速度會更快。當然,無論是開源的Mydumper還是官方最新的備份工具(5.7.11的mysqlpump)都支持了多線程備份,所以速度差異可能會進一步縮小,至少從目前生產環境來看,物理備份使用還是比較多的。由於Xtrabackup支持備份innodb表,實際生產環境中我們使用的工具是innobackupex,它是對xtrabackup的一層封裝。innobackupex 腳本用來備份非 InnoDB 表,同時會調用 xtrabackup 命令來備份 InnoDB 表,innobackupex的基本流程如下:


1.開啟redo日誌拷貝線程,從最新的檢查點開始順序拷貝redo日誌;
2.開啟ibd文件拷貝線程,拷貝innodb表的數據
3.ibd文件拷貝結束,通知調用FTWRL,獲取一致性位點
4.備份非innodb表(系統表)和frm文件
5.由於此時沒有新事務提交,等待redo日誌拷貝完成
6.最新的redo日誌拷貝完成後,相當於此時的innodb表和非innodb表數據都是最新的
7.獲取binlog位點,此時數據庫的狀態是一致的。
8.釋放鎖,備份結束。

完整備份過程如圖::
技術分享圖片

Xtrabackup的改進

無論是mysqldump,還是innobackupex備份工具,為了獲取一致性位點,都強依賴於FTWRL。這個鎖殺傷力非常大,因為持有鎖的這段時間,整個數據庫實質上不能對外提供寫服務的。此外,由於FTWRL需要關閉表,如有大查詢,會導致FTWRL等待,進而導致DML堵塞的時間變長。即使是備庫,也有SQL線程在復制來源於主庫的更新,上全局鎖時,會導致主備庫延遲。從前面的分析來看,FTWRL這把鎖持有的時間主要與非innodb表的數據量有關,如果非innodb表數據量很大,備份很慢,那麽持有鎖的時間就會很長。即使全部是innodb表,也會因為有mysql庫系統表存在,導致會鎖一定的時間。


為了解決這個問題,Percona公司對Mysql的Server層做了改進,引入了BACKUP LOCK。
具體而言,通過”LOCK TABLES FOR BACKUP”命令來備份非innodb表數據;通過”LOCK BINLOG FOR BACKUP”來獲取一致性位點,盡量減少因為數據庫備份帶來的服務受損。我們看看采用這兩個鎖與FTWRL的區別:

LOCK TABLES FOR BACKUP

作用:備份數據
1.禁止非innodb表更新
2.禁止所有表的ddl
優化點:
1.不會被大查詢堵塞(關閉表)
2.不會堵塞innodb表的讀取和更新,這點非常重要,對於業務表全部是innodb的情況,則備份過程中DML完全不受損
UNLOCK TABLES

LOCK BINLOG FOR BACKUP

作用:獲取一致性位點。
1.禁止對位點更新的操作
優化點:
1.允許DDl和更新,直到寫binlog為止。
UNLOCK BINLOG

準備和恢復數據階段

過程如圖:
首先應用xtrabackup日誌提交事務應用到InnoDB,然後回滾未提交事務。
技術分享圖片

增量備份過程

對於增量備份只對InnoDB,MyISAM和其它引擎仍然是完整備份的方式,增量備份主要是處理InnoDB中有變更的頁(頁的LSN).LSN信息在xtrabackup_checkpoints中。
技術分享圖片

增量應用

技術分享圖片

恢復過程

技術分享圖片

流備份過程圖

技術分享圖片

InnoDB表空間的結構

技術分享圖片

參考文章:
1.MySQL備份原理詳解
http://www.cnblogs.com/cchust/p/5452557.html

xtrabackup備份原理