xtrabackup的執行過程

XtraBackup的執行過程

執行全量備份過程中對數據庫進行的操作

可以看出執行xtrabackup進行全量備份總共有兩個線程

• SET SESSION lock_wait_timeout=31536000的作用是：因爲如果某個會話中使用了lock tables語句對某表加了鎖，或者某個會話在進行DDL，又或者某個會話正在進行一個大的事務，那麼flush tables和flush tables with read lock會被阻塞。設置鎖等待時間是爲了防止innobackup執行獲取全局鎖超時而導致備份失敗退出。

• FLUSH NO_WRITE_TO_BINLOG TABLES的作用是： 關閉所有打開的表，強制關閉所有正在使用的表，並刷新查詢緩存和預準備語句緩存。還會從查詢緩存中刪除查詢結果。默認情況下flush語句會寫入binlog，這裏使用no_write_to_binlog禁止記錄。查看Binlog發現，binlog內真的啥都沒記錄。

• FLUSH TABLES WITH READ LOCK的作用是：關閉所有被打開的表，並且使用全局鎖鎖住所有庫的所有表（鎖住之後只能被select，不能做其他操作）。當我們備份或者需要數據庫的一致狀態時，這個是最高效的方式。如果有事務存在，那麼該事務提交時會hang住，不會回滾。但是不會阻止數據庫往log tables（比如general_log和slow log）裏插入數據。

• FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS的作用是：將innodb層的重做日誌持久化到磁盤，然後再進行拷貝。說白了就是在所有的事務表和非事務表備份完成，獲取全局讀鎖，且使用了show master status語句獲取了binlog的pos之後，執行刷新redo log buffer中的日誌到磁盤中，然後redo log copy線程拷貝這最後的redo log日誌數據。爲啥這樣數據就是完整的？因爲獲取了全局讀鎖到unlock tables釋放之前，不會再有請求進來。

• UNLOCK TABLES的作用是：釋放全局讀鎖。

• 在flush tables with read lock和unlock tables之間，執行了下面操作
  a、 拷貝所有非事務表，如系統MyISAM表
  b、 將redo log buffer落盤
  c、 拷貝redo log

• XtraBackup備份全過程
  1、連接mysql進行版本檢查。
  2、通過讀取配置文件，獲取數據和日誌文件位置。
  3、掃描監控讀取redo log，有新的redo log就拷貝到xtrabackup的logfile中。
  4、拷貝共享表空間文件，innodb的.ibd數據文件
  5、關閉所有打開的表，獲取全局讀鎖，開始拷貝非Innodb的表和文件Starting to backup non-InnoDB tables and files
  6、將redo log落盤，拷貝到xtrabackup的logfile中。
  7、釋放全局讀鎖。
  8、記錄binlog信息等，備份結束。

• 對全備進行恢復時，並沒有對數據庫進行任何操作，全量日誌中無任何記錄

• 增量備份只針對innodb和全量備份的不同之處在於：
  A、在對增量innodb表等進行拷貝前，會統計變化的頁兒的數量
  SELECT 'INNODB_CHANGED_PAGES', COUNT(*) FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE 'INNODB_CHANGED_PAGES'
  
  B、使用全掃描進行增備，備份的共享表空間和ibd文件等都是增量，後綴爲.delta