愛可生 DBA 團隊成員，主要負責 MySQL 故障處理和 SQL 審覈優化。對技術執着，爲客戶負責。
概述
XtraBackup 是一款對於 MySQL 物理備份必不可少的工具，但是有時候在備份數據量級較大的數據庫時，如果未做優化的話，還是有點慢，當然相對於邏輯備份，已然是很快了，那到底還能不能再快一點呢，又是什麼參數在影響着 XtrBackup 的備份速度呢？帶着這個疑問我們往下看。
首先我們需要先了解 XtraBackup 的備份原理，話不多說直接看圖。
如圖所示：
1. 當 innobackupex 命令開始備份的時候，首先會啓動 xtrabackup 進程，xtrabackup 又分爲兩個線程，一個用於拷貝 ibd 文件，一個用於拷貝 redo 文件，redo 的拷貝線程只有一個，在 ibd 的拷貝線程啓動前啓動，在 ibd 的拷貝線程結束後結束。
2. xtrabackup 拷貝完成 idb 後，通知 innobackupex（通過創建文件），同時自己進入等待（redo 線程仍然繼續拷貝）
3. innobackupex 收到 xtrabackup 通知後，執行 FLUSH TABLES WITH READ LOCK (FTWRL)，取得一致性位置點，然後開始備份非 InnoDB 文件（包括 frm、MYD、MYI、CSV、opt、par 等）。拷貝非 InnoDB 文件過程中，因爲數據庫處於全局只讀狀態，非 InnoDB 表（主要 是MyISAM）如果比較多的話整庫只讀時間就會比較長。
4. 當 innobackupex 拷貝完所有非 InnoDB 表文件後，通知 xtrabackup（通過刪文件） ，同時自己進入等待（等待另一個文件被創建）；
5. xtrabackup 收到 innobackupex 備份完非 InnoDB 通知後，就停止 redo 拷貝線程，然後通知 innobackupex，redo log 拷貝完成（通過創建文件）；
6. innobackupex 收到 redo 備份完成通知後，就開始解鎖，執行 UNLOCK TABLES；
7. 最後 innobackupex 和 xtrabackup 進程各自完成收尾工作，如資源的釋放、寫備份元數據信息等，innobackupex 等待 xtrabackup 子進程結束後退出。
參數介紹
能夠讓我們加速備份的參數其實嚴格來說有以下兩個：
2. --compress-threads
先來說第一個參數 --parallel，先看下官方解釋：
也就是說，這個參數的作用是，在 XtraBackup 備份開始拷貝 ibd 文件的時候可以並行拷貝的線程數量，默認的話是單線程拷貝的，如果 ibd 文件較多的話只能拷貝完一個再繼續下一個，有一點需要注意如果表存儲在一個 ibd 文件中，那麼他將不會起到任何作用。
再看 --compress-threads 官網給出的解釋：
簡單來說就是針對 InnoDB 數據文件進行壓縮的線程數，在指定這個參數的時候無需加上 --compress 也可以實現壓縮。
測試
備份命令：
[root@TEST/data]# innobackupex --host=127.0.0.1 --user=root --password=123456 --port=3306 --parallel=4 --compress-threads=4 --stream=xbstream --tmpdir=/backup/tmp --no-version-check /backup >/backup/20210125/20210125`date +%H%M`
| 硬件 | 數據量 | 參數 | 所用時間 |
|---|---|---|---|
| 8C/8G | 100G | null | 20分鐘 |
| 8C/8G | 100G | --compress-threads=4 | 15分鐘 |
| 8C/8G | 100G | --parallel=4 | 12分鐘 |
| 8C/8G | 100G | --parallel=4;--compress-threads=4 | 8分鐘 |
相關推薦：
故障分析 | 記一次 MySQL 複製故障 -Error_code:1317
社區近期動態
點一下“閱讀原文”瞭解更多資訊
本文分享自微信公衆號 - 愛可生開源社區（ActiontechOSS）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。