備份的基本流程如下：

1. FLUSH TABLES

   功能：關閉實例上所有打開表
   目的：為第二步prepare，為了避免較長的事務操作造成FLUSH TABLES WITH READ LOCK操作遲遲得不到鎖，但同時又阻塞了其它客戶端操作

2. FLUSH TABLES WITH READ LOCK

   功能：加全局讀鎖
   目的：獲得DB一致性狀態

3. SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ

   功能：設置當前會話的事務隔離等級為RR，RR可避免不可重復讀和幻讀
   目的：確保在備份事務中任何時刻數據都相同

4. START TRANSACTION WITH CONSISTENT SNAPSHOT

   功能：獲取當前數據庫的快照，這個是由mysqldump中--single-transaction決定的
   目的： 簡而言之，就是開啟事務並對所有表執行了一次SELECT操作，這樣可保證備份時，在任意時間點執行select * from table得到的數據和執行START TRANSACTION WITH CONSISTENT SNAPSHOT時的數據一致

5. obtain Log position

   功能：獲取binlog的相關信息，這個是由--master-data決定的
   目的：記錄了開始備份時，binlog的狀態信息，包括MASTER_LOG_FILE和MASTER_LOG_POS

6. 備份非innodb表數據(.frm,.myi,.myd等)
   
7. unlock tables（非innodb表備份完畢）
   
8. 備份innodb表數據
   
9. 備份完成
   

xtrabackup備份原理

innobackupex的本質：innobackupex 腳本用來備份非 InnoDB 表，同時會調用 xtrabackup 命令來備份 InnoDB 表

備份的基本流程如下：

1. innobackupex 在啟動後，會先 fork 一個進程，啟動 xtrabackup進程，然後就等待 xtrabackup 備份完 ibd 數據文件
   ?
2. xtrabackup 在備份 InnoDB 相關數據時，是有2種線程的，1種是 redo 拷貝線程，負責拷貝 redo 文件，1種是 ibd 拷貝線程，負責拷貝 ibd 文件；redo 拷貝線程只有一個，在 ibd 拷貝線程之前啟動，在 ibd 線程結束後結束。xtrabackup 進程開始執行後，先啟動 redo 拷貝線程，從最新的 checkpoint 點開始順序拷貝 redo 日誌；然後再啟動 ibd 數據拷貝線程，在 xtrabackup 拷貝 ibd 過程中，innobackupex 進程一直處於等待狀態（等待文件被創建）
   
   ?
3. xtrabackup 拷貝完成idb後，通知 innobackupex（通過創建文件），同時自己進入等待（redo 線程仍然繼續拷貝）
   ?
4. innobackupex 收到 xtrabackup 通知後，執行FLUSH TABLES WITH READ LOCK (FTWRL)，取得一致性位點，然後開始備份非 InnoDB 文件（包括 frm、MYD、MYI、CSV、opt、par等）。拷貝非 InnoDB 文件過程中，因為數據庫處於全局只讀狀態，如果在業務的主庫備份的話，要特別小心，非 InnoDB 表（主要是MyISAM）比較多的話整庫只讀時間就會比較長，這個影響一定要評估到
   ?
5. 當 innobackupex 拷貝完所有非 InnoDB 表文件後，通知 xtrabackup（通過刪文件） ，同時自己進入等待（等待另一個文件被創建）
   ?
6. xtrabackup 收到 innobackupex 備份完非 InnoDB 通知後，就停止 redo 拷貝線程，然後通知 innobackupex redo log 拷貝完成（通過創建文件）
   ?
7. innobackupex 收到 redo 備份完成通知後，就開始解鎖，執行 UNLOCK TABLES
   ?
8. 最後 innobackupex 和 xtrabackup 進程各自完成收尾工作，如資源的釋放、寫備份元數據信息等，innobackupex 等待 xtrabackup 子進程結束後退出
   ?

邏輯備份mysqldump和物理備份xtrabackup的流程