物理備份(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