XtraBackup的執行過程

執行全量備份過程中對數據庫進行的操作
https://www.cnblogs.com/digdeep/p/4946230.html

可以看出執行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
  
• ================
• 6. innobackupex 選項優化/最佳實踐
  6.1 優化FTWRL鎖：
  在備份非innodb數據庫時，會使用：flush tables with read lock 全局鎖鎖住整個數據庫。如果數據庫中有一個長查詢在運行，那么FTWRL就不能獲得，會被阻塞，進而阻塞所有的DML操作。此時即使我們kill掉FTWRL全局鎖也是無法從阻塞中恢復出來的。另外在我們成功的獲得了FTWRL全局鎖之后，在copy非事務因為的文件的過程中，整個數據庫也是被鎖住的。所以我們應該讓FTWRL的過程盡量的短。(在copy非事務引擎數據的文件時，會阻塞innodb事務引擎。當然也會阻塞所有其他非事務引擎。)
  1> 防止阻塞：
  innobackupex 提供了多個選項來避免發生阻塞：
    --ftwrl-wait-timeout=# 替換 --lock-wait-timeout

                        This option specifies time in seconds that innobackupex

                        should wait for queries that would block FTWRL before

                        running it. If there are still such queries when the

                        timeout expires, innobackupex terminates with an error.

                        Default is 0, in which case innobackupex does not wait

                        for queries to complete and starts FTWRL immediately.

    --ftwrl-wait-threshold=# 替換 --lock-wait-threshold

                        This option specifies the query run time threshold which

                        is used by innobackupex to detect long-running queries

                        with a non-zero value of --ftwrl-wait-timeout. FTWRL is

                        not started until such long-running queries exist. This

                        option has no effect if --ftwrl-wait-timeout is 0.

                        Default value is 60 seconds.
  --lock-wait-timeout=60 該選項表示：我們在FTWRL時，如果有長查詢，那么我們可以最多等待60S的時間，如果60秒之內長查詢執行完了，我們就可以成功執行FTWRL了，如果60秒之內沒有執行完，那么就直接報錯退出，放棄。默認值為0
  --lock-wait-threshold=10 該選項表示運行了多久的時間的sql當做長查詢；對於長查詢最多再等待 --lock-wait-timeout 秒。
  --kill-long-queries-timeout=10 該選項表示發出FTWRL之后，再等待多時秒，如果還有長查詢，那么就將其kill掉。默認為0，not to kill.
  --kill-long-query-type={all|select} 該選項表示我們僅僅kill select語句，還是kill所有其他的類型的長sql語句。
  這幾個選項，我們沒有必要都是有，一般僅僅使用 --lock-wait-timeout=60 就行了。
  注意 --lock-* 和 --kill-* 選項的不同，一個是等待多時秒再來執行FTWRL，如果還是不能成功執行就報錯退出；一個是已經執行了FTWRL，超時就進行kill。
   
  2> 縮短FTWRL全局鎖的時間：
  --rsync 使用該選項來縮短備份非事務引擎表的鎖定時間，如果需要備份的數據庫和表數量很多時，可以加快速度。
  --rsync           Uses the rsync utility to optimize local file transfers.
                        When this option is specified, innobackupex uses rsync to

                        copy all non-InnoDB files instead of spawning a separate

                        cp for each file, which can be much faster for servers

                        with a large number of databases or tables.  This option

                        cannot be used together with --stream.
  3> 並行優化：
    --parallel=# 在備份階段，壓縮/解壓階段，加密/解密階段，--apply-log，--copy-back 階段都可以並行       

                        On backup, this option specifies the number of threads

                        the xtrabackup child process should use to back up files

                        concurrently.  The option accepts an integer argument. It

                        is passed directly to xtrabackup's --parallel option. See

                        the xtrabackup documentation for details.
  4> 內存優化：
    --use-memory=# 在crash recovery 階段，也就是 --apply-log 階段使用該選項

                        This option accepts a string argument that specifies the

                        amount of memory in bytes for xtrabackup to use for crash

                        recovery while preparing a backup. Multiples are

                        supported providing the unit (e.g. 1MB, 1GB). It is used

                        only with the option --apply-log. It is passed directly

                        to xtrabackup's --use-memory option. See the xtrabackup

                        documentation for details.
  3> 備份slave:

  --safe-slave-backup 

                        Stop slave SQL thread and wait to start backup until

                        Slave_open_temp_tables in "SHOW STATUS" is zero. If there

                        are no open temporary tables, the backup will take place,

                        otherwise the SQL thread will be started and stopped

                        until there are no open temporary tables. The backup will

                        fail if Slave_open_temp_tables does not become zero after

                        --safe-slave-backup-timeout seconds. The slave SQL thread

                        will be restarted when the backup finishes.

   

  --safe-slave-backup-timeout=#

                        How many seconds --safe-slave-backup should wait for

                        Slave_open_temp_tables to become zero. (default 300)

   

  --slave-info   This option is useful when backing up a replication slave

                        server. It prints the binary log position and name of the

                        master server. It also writes this information to the

                        "xtrabackup_slave_info" file as a "CHANGE MASTER"

                        command. A new slave for this master can be set up by

                        starting a slave server on this backup and issuing a

                        "CHANGE MASTER" command with the binary log position

                        saved in the "xtrabackup_slave_info" file.

   

  7. 備份原理：
  1）innobackupex 是perl寫的腳本，它調用xtrabackup來備份innodb數據庫。而xtrabackup是C語言寫的程序，它調用了innodb的函數庫和mysql客戶端的函數庫。innodb函數庫提供了向數據文件應用的redo log的功能，而mysql客戶端函數庫提供了解析命令行參數的功能。innobackupex備份innodb數據庫的功能，都是通過調用 xtrabackup --backup和xtrabackup --prepare來完成的。我們沒有必要直接使用xtrabackup來備份，通過innobackupex更方便。xtrabakup 通過跳轉到datadir目錄，然后通過兩個線程來完成備份過程：
  1> log-copy thread: 備份開始時，該后台線程一直監控redo log(每秒check一次redo log)，將redo log的修改復制到備份之后的文件 xtrabackup_logfile 中。如果redo log生成極快時，有可能log-copy線程跟不上redo log的產生速度，那么在redo log文件切換進行覆蓋時，xtrabakcup會報錯。
  2> data-file-copy thread: 前后有一個復制data file的線程，注意這里並不是簡單的復制，而是調用了innodb函數庫，像innodb數據庫那樣打開數據文件，進行讀取，然后每次復制一個page，然后對page進行驗證，如果驗證錯誤，會最多重復十次。
  當數據文件復制完成時，xtrabackup 停止log-copy 線程，並建立一個文件 xtrabackup_checkpoints記錄備份的類型，開始時的lsn和結束時的lsn等信息。
  而備份生成的 xtrabackup_binlog_info 文件則含義備份完成時對應的binlog的position信息，類似於：mysql-bin.000002        120
   
  在備份開始時記錄下LSN，然后一個線程復制數據文件，一個線程監控redo log，復制在備份過程中新產生的redo log。雖然我們的到的數據文件顯然不是一致性的，但是利用innodb的crash-recovery功能，應用備份過程中產生的redo log文件，就能得到備份完成時那一刻對應的一致性的數據。
   
  注意復制數據文件分成了兩個過程：
  一個是復制innodb事務引擎的數據文件，是不需要持有鎖的；另一個是復制非事務引擎的數據文件和table的定義文件.frm，復制這些文件時，是需要先通過FTWRL，然后在進行復制的，所以會導致整個數據庫被阻塞。
  增量備份時，是通過對表進行全掃描，比較LSN，如果該page的LSN大於上一次別分時的LSN，那么就將該page復制到table_name.ibd.delta文件中。回復時.delta會和redo log應用到全備是的數據文件中。
  增量備份在恢復時，除了最后一次增量備份文件之外，其它的增量備份在應用時，只能前滾，不能執行回滾操作，因為沒有提交的事務，可能在下一個增量備份中進行了提交，如果你在上一個增量備份時回滾了，那么下一個增量備份應用時，顯然就報錯了，因為他無法提交事務，該事務以及被回滾了。
• =========

• 1. 設置超時時間

  XtraBackup設置一個超時時間，避免無限期的等待。Xtrabackup提供了一下參數實現該功能：

  --lock-wait-timeout=SECONDS ：一旦Flush table with read lock被阻塞超過預定時間，則XtraBackup出錯返回退出，該值默認為0，也就是說一旦阻塞，立即返回失敗。

  --lock-wait-query-type=all|update ：該參數允許用戶指定，哪類的SQL語句是需要Flush table with read lock等待的，同時用戶可以通過–lock-wait-threshold=SECONDS設置等待的時間，如果不在query-type指定的類型范圍內或者超過了wait-threshold指定的時間，XtraBackup均返回錯誤。如果指定update類型，則UPDATE/ALTER/REPLACE /INSERT 均會等待，ALL表示所有的SQL語句。

  2. kill其他阻塞線程

  Kill掉所有阻塞Flush table with read lock的線程：

  --kill-long-queries-timeout=SECONDS ：參數允許用戶指定了超過該閾值時間的查詢會被Kill，同時也允許用戶指定Kill SQL語句的類型。

  --kill-long-query-type=all|select ：默認值為ALL，如果選擇Select，只有Select語句會被Kill，如果Flush table with read lock是被Update語句阻塞，則XtraBackup不會處理。

  數據庫運維人員在備份數據庫時，應選擇正確的XtraBackup版本規避該問題。同時，個人在使用XtraBackup在Slave做備份時，還碰到跟SQL線程產生死鎖的情況。MariaDB並行復制，死鎖信息如下：