物理備份(Xtrabackup)

轉載於：https://www.cnblogs.com/chinaops/p/9381649.html

相對於邏輯備份利用查詢提取資料中的所有記錄，物理備份更直接，拷貝資料庫檔案和日誌來完成備份，因此速度會更快。當然，無論是開源的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表空間的結構

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