xtrabackup備份原理及注意事項

原創

2020-02-21 03:07

物理備份(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的區別：