導語 在使用xtrabackup8版本對mysql8版本進行備份恢復搭建從庫的時候，繼續使用xtrabackup2版本的方式，從xtrabackup_binlog_info 文件中找到gtid信息，執行purge，嘗試多次發現搭建失敗，於是對xtrabackup2和xtrbackup8版本備份流程（ ...
導語
在使用xtrabackup8版本對mysql8版本進行備份恢復搭建從庫的時候，繼續使用xtrabackup2版本的方式，從xtrabackup_binlog_info 文件中找到gtid信息，執行purge，嘗試多次發現搭建失敗，於是對xtrabackup2和xtrbackup8版本備份流程（依據官網）進行了簡單的分析和測試。
1、xtrabackup2.4版本備份mysql5.7流程
（1）整體流程：
xtrabackup是物理備份，通過複製數據文件來進行備份的，在複製innodb數據文件的時候，會導致數據內部不一致，但是由於redo事務日誌的存在（它包含對innodb數據修改的記錄），當innodb啟動的時候會檢查數據文件和事務日誌，該提交提交該回滾回滾，從而保證了一致性。
xtrabackup在啟動的時候會記住日誌序列號（LSN），然後複製數據文件，然而當數據量較大的時候，複製數據文件是需要一定的時間的，如果該時間內不斷有寫入業務的話，那麼將會使資料庫處於不同的時間點。這時xtrabackup會從後臺啟動一個事務日誌監測進程（每秒檢測一次），並不斷的複製事務日誌的修改，由於事務日誌是迴圈的方式寫的，所以在xtrabackup開始的時候就會不斷的複製事務日誌的修改。
將使用ftwrl加全局讀鎖，來備份非innodb表，並且寫xtrabackup_binlog_info文件，使用FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS來刷盤redo log，阻止所有可能改變二進位日誌位置或Exec_Master_Log_Pos或Exec_Gtid_Set的操作，然後停止redo log的複製操作，解鎖二進位日誌和表，然後寫xtrabackup_info文件，備份完成。
（2）流程總結：
對於上述的備份過程整體簡單總結一下就是：
①開始備份，連接資料庫併進行許可權校驗以及確認版本（version_check Connected to MySQL server）；
②備份innodb表，並開啟後臺線程拷貝redo log事務日誌（>> log scanned up to (952373638).....）；
③innodb表備份完成後，加ftwrl全局讀鎖來copy非innodb表文件，拷貝完成後（Finished backing up non-InnoDB tables and files）通過show master status寫xtrabackup_binlog_info文件；
④將redo log buffer中的redo log進行刷盤（Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...）；
⑤停止拷貝事務日誌（Stopping log copying thread.）；
⑥解鎖二進位日誌和表（Executing UNLOCK TABLES）；
⑦寫xtrabackup_info文件（Writing /data0/backup/9909/base/xtrabackup_info）；
⑧備份完成。
（3）關於恢復後binlog信息位置點：
可以創建一個存儲過程，來模擬數據的插入。
①首先進行一次全備份：
xtrabackup --defaults-file=/etc/mysql/9909.cnf --backup --user=root --password=root --parallel=4 --ftwrl-wait-timeout=60 --ftwrl-wait-threshold=3 --rsync --socket=/tmp/mysql_9909.sock --target-dir=/data0/backup/9909/base
②進行prepare階段：
xtrabackup --prepare --apply-log-only --target-dir=/data0/backup/9909/base/
③查看xtrabackup_binlog_info 文件binlog點位信息：
mysql-bin.000026 1251702 9c94ddb7-7397-11ec-a69f-fa37ddbb3200:1-38088
④用備份文件啟動mysql，查看binlog點位信息：
mysql> show master stauts;9c94ddb7-7397-11ec-a69f-fa37ddbb3200:1-34381可以看到該點位比xtrabackup_binlog_info要差很多，查看原來實例的binlog找到該兩個gtid信息位置：9c94ddb7-7397-11ec-a69f-fa37ddbb3200:38088此處是一個insert語句：
我們在恢復的庫中進行查詢看看有沒有這條記錄，可以看到有這條記錄，並且下一條記錄就沒了（因為上面的存儲過程是按順序插入的）：
所以說在9c94ddb7-7397-11ec-a69f-fa37ddbb3200:38088之前的記錄都已經存在了，而show master status查詢出來的要落後好多，如果使用該binlog點位搭建從庫的話（不執行purge）會出問題的，比如會出現主鍵衝突等。
（4）原因：在備份的時候通過show master status讀取binlog信息，因為開啟了binlog日誌，所以show master status讀取的是show global variables查出來的gtid的信息，然後保存到了xtrabackup_binlog_info文件中。這裡使用的是備份文件進行啟動的實例，binlog從1號開始，所以需要讀取這個表，所以查出來的show master status是通過這個表來獲取的，而這個表在原庫沒有更新過，所以會比xtrabackup_binlog_info文件中的gtid要少。
（5）補充：
在恢復的時候，需要進行準備階段，該階段使用複製的事務日誌文件對數據文件進行崩潰恢復，完成之後，資料庫就可以恢復和使用了。備份的非innodb表和innodb表最終保持一致，因為在準備階段，innodb的數據會前滾到備份完成的點，而不是回滾。這個時間點和ftwrl的時間點相匹配，所以mysiam和innodb數據是一致的。
2、xtrabackup8.0版本備份mysql8.0流程
（1）整體流程：
xtrabackup是物理備份，通過複製數據文件來進行備份的，在複製innodb數據文件的時候，會導致數據內部不一致，但是由於redo事務日誌的存在（它包含對innodb數據修改的記錄），當innodb啟動的時候會檢查數據文件和事務日誌，該提交提交該回滾回滾，從而保證了一致性。
xtrabackup在啟動的時候會記住日誌序列號（LSN），然後複製數據文件，然而當數據量較大的時候，複製數據文件是需要一定的時間的，如果該時間內不斷有寫入業務的話，那麼將會使資料庫處於不同的時間點。這時xtrabackup會從後臺啟動一個事務日誌監測進程（每秒檢測一次），並不斷的複製事務日誌的修改，由於事務日誌是迴圈的方式寫的，所以在xtrabackup開始的時候就會不斷的複製事務日誌的修改。
xtrabackup8在備份mysql8版本的時候，使用備份鎖來代替ftwrl（mysql8通過lock instance for backup語句獲取一個實例級備份鎖）。當只有innodb表時，xtrabackup將儘可能避免使用備份鎖和ftwrl。xtrabackup從performance_schema.log_status來獲取二進位日誌的信息。在mysql8中如果xtrabackup使用--slave-info參數或者存在非innodb表的時候（除了系統表），仍然需要ftwrl進行加鎖。當支持備份鎖時，xtrabackup會先拷貝innodb數據，然後運行lock tables for backup再拷貝myisam表。
在此之後，使用FLUSH NO_WRITE_TO_BINLOG BINARY LOGS切換binlog，並讀取log_status表，使用FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS來刷盤redo log，阻止所有可能改變二進位日誌位置的操作，然後將完成redo日誌文件的複製，並獲取二進位日誌信息。完成後，將解鎖二進位日誌和表。然後寫xtrabackup_info文件，備份完成。
（2）流程總結：對於上述的備份過程分兩種情況簡單總結一下就是：
a、只有innodb表：
①開始備份，連接資料庫併進行許可權校驗以及確認版本（version_check Connected to MySQL server）；
②備份innodb表，並開啟後臺線程拷貝redo log事務日誌（>> log scanned up to (952373638).....）；
③innodb表備份完成後，copy非innodb表文件，拷貝完成後（Finished backing up non-InnoDB tables and files）通過切換binlog（Executing FLUSH NO_WRITE_TO_BINLOG BINARY LOGS）並查詢log_status表（Selecting LSN and binary log position from p_s.log_status）；
④拷貝新的binlog（Copying /data0/mysql/8001_test/mysql-bin.000011 to /data0/backup/8001/base/mysql-bin.000011），寫mysql-bin.index文件和xtrabackup_binlog_info文件；
④將redo log buffer中的redo log進行刷盤（Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...）；
⑤停止拷貝事務日誌（Stopping log copying thread.）；
⑥解鎖二進位日誌和表（Executing UNLOCK TABLES）；
⑦寫xtrabackup_info文件（Writing /data0/backup/9909/base/xtrabackup_info）；
⑧備份完成。
b、包含myisam表：
①開始備份，連接資料庫併進行許可權校驗以及確認版本（version_check Connected to MySQL server）；
②備份innodb表，並開啟後臺線程拷貝redo log事務日誌（>> log scanned up to (952373638).....）；
③innodb表備份完成後，加ftwrl全局讀鎖來copy非innodb表文件，拷貝完成後（Finished backing up non-InnoDB tables and files）通過切換binlog（Executing FLUSH NO_WRITE_TO_BINLOG BINARY LOGS）並查詢log_status表（Selecting LSN and binary log position from p_s.log_status）；
④拷貝新的binlog（Copying /data0/mysql/8001_test/mysql-bin.000011 to /data0/backup/8001/base/mysql-bin.000011），寫mysql-bin.index文件和xtrabackup_binlog_info文件；將redo log buffer中的redo log進行刷盤（Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...）；
⑤停止拷貝事務日誌（Stopping log copying thread.）；
⑥解鎖二進位日誌和表（Executing UNLOCK TABLES）；
⑦寫xtrabackup_info文件（Writing /data0/backup/9909/base/xtrabackup_info）；
⑧備份完成。
其實只有innodb表和包含myisam表，xtrbackup8備份的時候差別在於包含myisam表的時候增加了ftwrl操作。
（3）performance_schema.log_status表簡介：
該表是為線上備份工具來使用的，提供了日誌的信息，當查詢log_status表時，伺服器阻塞日誌記錄和相關管理更改，時間足夠填充表，然後釋放資源。
該表通知線上備份工具應該複製到二進位日誌的哪個點以及每個通道的中繼日誌的信息。還提供了單個存儲引擎的相關信息，例如最近的日誌序列號（LSN）和innodb存儲引擎的最後一個檢查點的LSN。註意該表不允許執行truncate table。
（4）lock instance for backup簡介：
是一個實例級別的備份鎖，允許在聯機備份期間進行DML操作。執行該命令需要backup_admin許可權，當從早期版本升級到mysql8.0版本時，該許可權會自動授權具有reload許可權的用戶。該備份鎖防止文件被創建、重命名或者刪除（比如repair table、truncate table、optimizer table等），對於redo中沒有記錄的修改的操作也會被阻止。
（5）關於恢復後binlog信息位置點（只測試只有innodb表的時候）可以創建一個存儲過程，來模擬數據的插入。
①首先進行一次全備份：xtrabackup8 --defaults-file=/etc/mysql/8001.cnf --backup --user=root --password=root --parallel=4 --ftwrl-wait-timeout=60 --ftwrl-wait-threshold=3 --rsync --socket=/data0/mysql/8001_test/mysql_8001.sock --target-dir=/data0/backup/8001/base
②進行prepare階段：
xtrabackup8 --prepare --apply-log-only --target-dir=/data0/backup/8001/base/
③查看xtrabackup_binlog_info 文件binlog點位信息：
mysql-bin.000027 1027 c8020369-d117-11ec-9049-fa37ddbb3200:1-96358
④用備份文件啟動mysql，查看binlog點位信息：
mysql> show master stauts;c8020369-d117-11ec-9049-fa37ddbb3200:1-96359可以看到該點位比xtrabackup_binlog_info 文件binlog點位要大，到底哪個是準確的呢？來看一下binlog：
已經存在該數據了，如果當做從庫的話，還是從xtrabackup_binlog_info該文件去查找binlog點位然後執行purge，那麼搭建起來的從庫會報錯，比如主鍵衝突等，或者造成數據不一致。所以xtrabackup8備份mysql8之後show master status就是正確的binglog點位，不用再去執行purge。
⑤原因：
因為xtrabackup8中在備份過程中多了兩個步驟：
第一：切換binlog；
第二：拷貝新的binlog，並寫mysql-bin.index文件。當使用備份啟動實例的時候，由於binlog存在，所以啟動的時候從binlog去讀取點位信息，並更新mysql.gtid_executed表。
看一下原庫的p_s.log_status表：
該表主要的作用就是，在備份過程中提供一致性點位，在查詢該表之後會執行Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...來阻止可能改變二進位位置的操作。
3、補充
①xtrabackup_binlog_info 文件binlog點位信息：1027position對應的gtid是： c8020369-d117-11ec-9049-fa37ddbb3200:96358而實際上1027position對應的gtid是： c8020369-d117-11ec-9049-fa37ddbb3200:96359可見xtrabackup_binlog_info 中的並不准確。
參考：
