標籤：參數 最佳實務 opp table ase 使用者 tail 恢複 min
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並行複製，死結資訊如下：
xtrabackup的執行過程
