XtraBackup工具詳解 Part 3 XtraBackup工作原理

實驗環境

此次實驗的環境如下

• MySQL 5.7.25

• Redhat 6.10

1. Percona XtraBackup 備份原理

Percona XtraBackup 利用的是InnoDB的crash-recovery功能

他拷貝非一致狀態的InnoDB資料檔案,之後利用redo日誌對資料檔案做恢復以使資料檔案一致

這是因為InnoDB維護了一個記錄InnoDB資料更改的重做日誌(redo log)，也可以稱為事務日誌

恢復時，Percona XtraBackup檢查資料檔案和事務日誌，之後做兩個步驟：

• 將提交過的事務寫到資料檔案中
• 回滾未提交的事務

Percona XtraBackup 備份開始時，首先記錄日誌的序號(log sequence number
或者LSN)。之後拷貝資料檔案，與此同時，Percona XtraBackup 啟動一個後臺程式監視重做日誌，之後拷貝改變的部分

因為重做日誌會被覆蓋，所以Percona XtraBackup必須時刻監視著

2. Percona XtraBackup備份過程

Percona Server 5.6開始，Percona XtraBackup新增了backup lock特性，他相對與
FLUSH TABLES WITH READ LOCK來說更加的輕量級，使用它可以在不影響InnoDB表的DML操作下拷貝非InnoDB資料

backup lock 包括如下三個命令：

• LOCK TABLES FOR BACKUP

• LOCK BINLOG FOR BACKUP

• UNLOCK BINLOG

最後大體上xtrabackup的步驟如下:

• 首先會記錄LSN位置並拷貝InnoDB資料檔案並持續跟蹤LSN變化
• InnoDB拷貝完之後執行執行LOCK TABLES FOR BACKUP命令阻止非InnoDB表的DML操作
• 之後拷貝非InnoDB資料檔案，如MyISAM等
• 之後執行LOCK BINLOG FOR BACKUP命令阻止所有可能更改二進位制日誌位置或者GTID的操作
• 之後拷貝改變redo日誌
• 最後釋放二進位制日誌和表的鎖(UNLOCK BINLOG)

這樣就保證了備份完成後innodb和非innodb的資料是一致的

注意上述過程為Percona Server 5.6及以上，對於社群版的MySQL使用的是如下命令進行上鎖

• FLUSH NO_WRITE_TO_BINLOG TABLES

• FLUSH TABLES WITH READ LOCK

這意味著當備份完innodb表後，非innodb的表會導致全域性的讀鎖，即不允許DML操作

另外如果備份時有長時間未結束的語句或者系統繁忙時，FLUSH TABLES WITH READ LOCK會消耗很長時間，將導致資料庫長時間無法DML操作

所以建議MySQL不要使用MyISAM引擎的表並在系統空閒時進行備份

3. Percona XtraBackup還原原理

使用 xtrabackup --copy-back 或 xtrabackup --move-back將備份的檔案還原到一個目錄

相當於Oracle的restore

預設情況下,  它會讀取my.cnf檔案中的datadir, innodb_data_home_dir, innodb_data_file_path, innodb_log_group_home_dir變數並檢查目錄是否存在

還原檔案的順序如下:

• 首先是MyISAM的表和索引以及其他非innodb的資料(如.frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSM, .CSV, par and .opt 檔案)
• 之後拷貝innodb的表和索引
• 最後是redo log

之後是恢復資料，相當與oracle的recover，即使用redo log做恢復以使資料達到一致狀態

4. 參考資料

本專題所有內容翻譯子Percona XtraBackup的官方文件

可通過如下連結下載

http://www.zhaibibei.cn/mysql/xtrabackup/tutorial1