概述
TiDB 支持使用 br 工具進行備份恢復问词。
安裝方法可以使用 TiUP 在線安裝：
tiup install br
使用備份恢復功能的部署要求如下：
- BR、TiKV 節(jié)點和備份存儲系統(tǒng)需要提供大于備份速度的的網(wǎng)絡(luò)帶寬勺馆。當集群特別大的時候戏售，備份和恢復速度上限受限于備份網(wǎng)絡(luò)的帶寬侨核。
- 備份存儲系統(tǒng)還需要提供足夠的寫入/讀取性能 (IOPS)，否則它有可能成為備份恢復時的性能瓶頸灌灾。
- TiKV 節(jié)點需要為備份準備至少額外的兩個 CPU core 和高性能的磁盤搓译，否則備份將對集群上運行的業(yè)務(wù)產(chǎn)生影響。
- 推薦 br 工具運行在 8 核+/16 GB+ 的節(jié)點上锋喜。
備份目錄的用戶所屬組是 tidb.tidb些己，
tikv節(jié)點的備份目錄下存放的是實際備份的數(shù)據(jù)，而pd節(jié)點存放的是備份的元數(shù)據(jù)嘿般。
注：
不支持在一個集群上同時運行多個數(shù)據(jù)備份任務(wù)段标。
不支持在一個集群上同時運行快照備份任務(wù)和數(shù)據(jù)恢復任務(wù)。
TiDB 快照備份
快照備份是集群全量備份的一種實現(xiàn)炉奴。
它基于 TiDB 的MVCC實現(xiàn)逼庞，將指定快照包含的所有數(shù)據(jù)備份到目標存儲中。
備份下來的數(shù)據(jù)大小約等于集群（壓縮后的）單副本數(shù)據(jù)大小瞻赶。
備份完成之后赛糟，可以在一個空集群或不存在數(shù)據(jù)沖突（相同 schema 或 table）的集群執(zhí)行快照備份恢復，將集群恢復到快照備份時的數(shù)據(jù)狀態(tài)砸逊，同時恢復功能會依據(jù)集群副本設(shè)置恢復出多副本璧南。
快照備份命令：
tiup br backup full --pd "${PD_IP}:2379" \
--backupts '2022-09-08 13:30:00 +08:00' \
--storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" \
--ratelimit 128 \
以上命令中：
-
--backupts：快照對應(yīng)的物理時間點，格式可以是 TSO 或者時間戳师逸，例如400036290571534337或者2018-05-11 01:42:23 +08:00司倚。如果該快照的數(shù)據(jù)被垃圾回收 (GC) 了，那么tiup br backup命令會報錯并退出篓像。使用日期方式備份時动知，建議同時指定時區(qū)，否則 br 默認使用本地時間構(gòu)造時間戳遗淳，可能導致備份時間點錯誤拍柒。如果你沒有指定該參數(shù)，那么 br 會選取備份開始的時間點所對應(yīng)的快照屈暗。 -
--storage：數(shù)據(jù)備份到的存儲地址拆讯。快照備份支持以 Amazon S3养叛、Google Cloud Storage种呐、Azure Blob Storage 為備份存儲，以上命令以 Amazon S3 為示例弃甥。詳細存儲地址格式請參考外部存儲服務(wù)的 URI 格式爽室。 -
--ratelimit：每個TiKV備份數(shù)據(jù)的速度上限，單位為 MiB/s淆攻。
查看詳細使用幫助：
tiup br backup full --help
我們使用測試環(huán)境驗證備份單庫：
cd /home/tidb/.tiup/bin
./tiup br backup db --db pingcap_test01 --pd "10.0.8.88:2379" --storage "/backup/tidb_backup" --ratelimit 128
在快照備份過程中阔墩，終端會顯示備份進度條嘿架。在備份完成后，會輸出備份耗時啸箫、速度耸彪、備份數(shù)據(jù)大小等信息：
Starting component br: /home/tidb/.tiup/components/br/v8.1.1/br backup db --db pingcap_test01 --pd 10.0.8.88:2379 --storage /backup/tidb_backup --ratelimit 128
Detail BR log in /tmp/br.log.2024-10-21T15.53.14+0800
[2024/10/21 15:53:14.721 +08:00] [WARN] [backup.go:311] ["setting `--ratelimit` and `--concurrency` at the same time, ignoring `--concurrency`: `--ratelimit` forces sequential (i.e. concurrency = 1) backup"] [ratelimit=134.2MB/s] [concurrency-specified=4]
Database Backup <------------------------------------------------------------------------------------------------------------------------------------> 100.00%
Checksum <-------------------------------------------------------------------------------------------------------------------------------------------> 100.00%
[2024/10/21 15:53:18.912 +08:00] [INFO] [collector.go:77] ["Database Backup success summary"] [total-ranges=2] [ranges-succeed=2] [ranges-failed=0] [backup-checksum=9.930648ms] [backup-fast-checksum=5.479934ms] [backup-total-ranges=2] [backup-total-regions=2] [total-take=4.19936762s] [total-kv=2] [total-kv-size=88B] [average-speed=20.96B/s] [backup-data-size(after-compressed)=3.288kB] [Size=3288] [BackupTS=453377312893173767]
備份路徑下會生成以下兩種類型文件：
- SST 文件：存儲 TiKV 備份下來的數(shù)據(jù)信息
- backupmeta 文件：存儲本次備份的元信息，包括備份文件數(shù)忘苛、備份文件的 Key 區(qū)間蝉娜、備份文件大小和備份文件 Hash (sha256) 值
查詢快照備份的時間點信息
查看某個快照備份對應(yīng)的快照物理時間點：
tiup br validate decode --field="end-version" \
--storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" | tail -n1
測試環(huán)境里執(zhí)行：
tiup br validate decode --field="end-version" --storage "/backup/tidb_backup"
輸出結(jié)果為：
Starting component br: /home/tidb/.tiup/components/br/v8.1.1/br validate decode --field=end-version --storage /backup/tidb_backup
Detail BR log in /tmp/br.log.2024-10-21T16.46.41+0800
453377312893173767
恢復快照備份數(shù)據(jù)
查看詳細使用幫助：
tiup br restore full --help
恢復到目標集群：
tiup br restore full --pd "${PD_IP}:2379" \
--storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}"
測試環(huán)境恢復：
./tiup br restore full --pd "10.0.8.88:2379" --storage "/backup/tidb_backup"
恢復單庫：
./tiup br restore db --db pingcap_test01 --pd "10.0.8.88:2379" --storage "/backup/tidb_backup"
恢復單表：
./tiup br restore table --db pingcap_test01 --table tab_tidb --pd "10.0.8.88:2379" --storage "/backup/tidb_backup"
使用表庫過濾功能恢復部分數(shù)據(jù)：
./tiup br restore full --pd "10.0.8.88:2379" --filter 'pingcap_test01.tab_tidb' --storage "/backup/tidb_backup"
測試打印結(jié)果為：
Starting component br: /home/tidb/.tiup/components/br/v8.1.1/br restore full --pd 10.0.8.88:2379 --filter pingcap_test01.tab_tidb --storage /backup/tidb_backup
Detail BR log in /tmp/br.log.2024-10-21T17.18.32+0800
Full Restore <---------------------------------------------------------------------------------------------------------------------------------------> 100.00%
[2024/10/21 17:18:37.004 +08:00] [INFO] [collector.go:77] ["Full Restore success summary"] [total-ranges=3] [ranges-succeed=3] [ranges-failed=0] [split-region=1.361125ms] [restore-ranges=2] [total-take=4.679754552s] [restore-data-size(after-compressed)=3.288kB] [Size=3288] [BackupTS=453377312893173767] [RestoreTS=453378654244438017] [total-kv=2] [total-kv-size=88B] [average-speed=18.8B/s]
再檢查數(shù)據(jù)庫相應(yīng)數(shù)據(jù)已恢復。
性能與影響
快照備份的性能與影響
TiDB 備份功能對集群性能（事務(wù)延遲和 QPS）有一定的影響扎唾，但是可以通過調(diào)整備份的線程數(shù) backup.num-threads召川，以及增加集群配置，來降低備份對集群性能的影響胸遇。
為了更加具體說明備份對集群的影響荧呐，下面列舉了多次快照備份測試結(jié)論來說明影響的范圍：
- （使用 5.3 及之前版本）在默認配置下，單 TiKV 存儲節(jié)點上備份線程數(shù)量是節(jié)點 CPU 總數(shù)量的 75% 時狐榔，QPS 會下降到備份之前的 35% 左右坛增。
- （使用 5.4 及以后版本）單 TiKV 存儲節(jié)點上備份的線程數(shù)量不大于
8、集群總 CPU 利用率不超過 80% 時薄腻，備份任務(wù)對集群（無論讀寫負載）影響最大在 20% 左右。 - （使用 5.4 及以后版本）單 TiKV 存儲節(jié)點上備份的線程數(shù)量不大于
8届案、集群總 CPU 利用率不超過 75% 時庵楷，備份任務(wù)對集群（無論讀寫負載）影響最大在 10% 左右。 - （使用 5.4 及以后版本）單 TiKV 存儲節(jié)點上備份的線程數(shù)量不大于
8楣颠、集群總 CPU 利用率不超過 60% 時尽纽，備份任務(wù)對集群（無論讀寫負載）幾乎沒有影響。
你可以通過如下方案手動控制備份對集群性能帶來的影響童漩。但是弄贿，這兩種方案在減少備份對集群的影響的同時，也會降低備份任務(wù)的速度矫膨。
- 使用
--ratelimit參數(shù)對備份任務(wù)進行限速差凹。請注意，這個參數(shù)限制的是把備份文件存儲到外部存儲的速度侧馅。計算備份文件的大小時危尿，請以備份日志中的backup data size(after compressed)為準。設(shè)置--ratelimit后馁痴，為了避免任務(wù)數(shù)過多導致限速失效谊娇，br 的concurrency參數(shù)會自動調(diào)整為 1。 - 調(diào)節(jié) TiKV 配置項
backup.num-threads罗晕，限制備份任務(wù)使用的工作線程數(shù)量济欢。內(nèi)部測試數(shù)據(jù)表明赠堵，當備份的線程數(shù)量不大于8、集群總 CPU 利用率不超過 60% 時法褥，備份任務(wù)對集群（無論讀寫負載）幾乎沒有影響茫叭。
通過限制備份的線程數(shù)量可以降低備份對集群性能的影響，但是這會影響到備份的性能挖胃，以上的多次備份測試結(jié)果顯示杂靶，單 TiKV 存儲節(jié)點上備份速度和備份線程數(shù)量呈正比。在線程數(shù)量較少的時候酱鸭，備份速度約為 20 MiB/線程數(shù)吗垮。例如，單 TiKV 節(jié)點 5 個備份線程可達到 100 MiB/s 的備份速度凹髓。
快照恢復的性能與影響
-
TiDB 恢復的時候會盡可能打滿 TiKV CPU烁登、磁盤 IO、網(wǎng)絡(luò)帶寬等資源蔚舀，所以推薦在空的集群上執(zhí)行備份數(shù)據(jù)的恢復饵沧，避免對正在運行的業(yè)務(wù)產(chǎn)生影響。
備份數(shù)據(jù)的恢復速度與集群配置赌躺、部署狼牺、運行的業(yè)務(wù)都有比較大的關(guān)系。在內(nèi)部多場景仿真測試中礼患，單 TiKV 存儲節(jié)點上備份數(shù)據(jù)恢復速度能夠達到 100 MiB/s是钥。在不同用戶場景下，快照恢復的性能和影響應(yīng)以實際測試結(jié)論為準缅叠。
BR 提供了粗粒度的 Region 打散算法悄泥，用于提升大規(guī)模 Region 場景下的 Region 恢復速度。該算法通過命令行參數(shù)
--granularity="coarse-grained"控制肤粱，并默認啟用弹囚。在這個方式下每個 TiKV 節(jié)點會得到均勻穩(wěn)定的下載任務(wù)，從而充分利用每個 TiKV 節(jié)點的所有資源實現(xiàn)并行快速恢復领曼。在實際案例中鸥鹉，大規(guī)模 Region 場景下，集群快照恢復速度最高提升約 3 倍悯森。使用示例如下：
br restore full \ --pd "${PDIP}:2379" \ --storage "s3://${Bucket}/${Folder}" \ --s3.region "${region}" \ --granularity "coarse-grained" \ --send-credentials-to-tikv=true \ --log-file restorefull.log- 從 v8.0.0 起欣喧，
br命令行工具新增--tikv-max-restore-concurrency參數(shù)谬运，用于控制每個 TiKV 節(jié)點的最大 download 和 ingest 文件數(shù)量。此外，通過調(diào)整此參數(shù)遥赚，可以控制作業(yè)隊列的最大長度（作業(yè)隊列的最大長度 = 32 * TiKV 節(jié)點數(shù)量 *--tikv-max-restore-concurrency），進而控制 BR 節(jié)點的內(nèi)存消耗。
通常情況下，
--tikv-max-restore-concurrency會根據(jù)集群配置自動調(diào)整细溅，無需手動設(shè)置。如果通過 Grafana 中的 TiKV-Details > Backup & Import > Import RPC count 監(jiān)控指標發(fā)現(xiàn) download 文件數(shù)量長時間接近于 0儡嘶，而 ingest 文件數(shù)量一直處于上限時喇聊，說明 ingest 文件任務(wù)存在堆積，并且作業(yè)隊列已達到最大長度蹦狂。此時誓篱，可以采取以下措施來緩解任務(wù)堆積問題：- 設(shè)置
--ratelimit參數(shù)來限制下載速度，以確保 ingest 文件任務(wù)有足夠的資源凯楔。例如窜骄，當任意 TiKV 節(jié)點的硬盤吞吐量為x MiB/s且下載備份文件的網(wǎng)絡(luò)帶寬大于x/2 MiB/s，可以設(shè)置參數(shù)--ratelimit x/2摆屯。如果任意 TiKV 節(jié)點的硬盤吞吐量為x MiB/s且下載備份文件的網(wǎng)絡(luò)帶寬小于或等于x/2 MiB/s邻遏，可以不設(shè)置參數(shù)--ratelimit。 - 調(diào)高
--tikv-max-restore-concurrency來增加作業(yè)隊列的最大長度虐骑。
參考手冊：
https://docs.pingcap.com/zh/tidb/stable/br-snapshot-guide
