備份的 “運算元下推”:BR 簡介丨TiDB 工具分享

語言: CN / TW / HK

BR 選擇了在 Transaction KV 層面進行掃描來實現備份,這樣,備份的核心便是分佈在多個 TiKV 節點上的 MVCC Scan:簡單,粗暴,但是有效,它生來就繼承了 TiKV 的諸多優勢: 分散式、利於橫向拓展、靈活(可以備份任意範圍、未 GC 的任意版本的資料)等等優點

相較於從前只能使用 mydumper 進行 SQL 層的備份,BR 能夠更加高效地備份和恢復:它取消了 SQL 層的開銷,同時支援備份索引,而且所有備份都是已經排序的 SST 檔案,以此大大加速了恢復。

BR 的實力在之前的文章( https://pingcap.com/zh/blog/cluster-data-security-backup )中已經展示過了,本文將會詳細描述 BR 備份側的具體實現:簡單來講,BR 就是備份的 “運算元下推”:通過 gRPC 介面,將任務下發給 TiKV,然後讓 TiKV 自己將資料轉儲到外部儲存中。

BR 的基本流程

介面

為了區別於一般的 MVCC Scan 請求,TiKV 提供一個叫做  Backup 的介面,這個介面與一般的讀請求不同——它不會返回資料給客戶端,而是直接將讀到的資料儲存到指定的儲存器(External Stroage)中:
service Backup {
// 收到 backup 的 TiKV,將會將 Request 指定範圍中,所有自身為 leader
// 的 region 備份,並流式地返回給客戶端(每個 region 對應流中的一個 item)。
rpc backup(BackupRequest) returns (stream BackupResponse) {}
}

// NOTE:隱藏了一些不重要的 field 。
message BackupRequest {
// 備份的範圍,[start_key, end_key)。
bytes start_key = 2;
bytes end_key = 3;
// 備份的 MVCC 版本。
uint64 start_version = 4;
uint64 end_version = 5;

// 限流介面,為了確保和恢復時候的一致性,限流限制儲存備份檔案的階段的速度。
uint64 rate_limit = 7;

// 備份的目標儲存。
StorageBackend storage_backend = 9;
// 備份的壓縮 -- 這是一個用 CPU 資源換取 I/O 頻寬的優化。
CompressionType compression_type = 12;
int32 compression_level = 13;
// 備份支援加密。
CipherInfo cipher_info = 14;
}

message BackupResponse {
Error error = 1;
// 備份的請求將會返回多次,每次都會返回一個已經完成的子範圍。
// 利用這些資訊可以統計備份進度。
bytes start_key = 2;
bytes end_key = 3;
// 返回該範圍備份檔案的列表,用於恢復的時候追蹤。
repeated File files = 4;
}

客戶端

BR 客戶端會藉助 TiDB 的介面,根據使用者指定需要備份的庫和表,計算出來需要備份的範圍(ranges)。計算的依據是:

  1. 依據每個 table 的所有 data key 生成 range。(所有帶有 t{table_id}_r 字首的 Key)

  2. 依據每個 index 的所有 index key 生成 range。(所有帶有 t{table_id}_i{index_id} 字首的 Key)

  3. 如果 table 存在 partition(這意味著,它可能有多個 table ID),對於每個 partition,按照上述規則生成 range。

為了獲得最大的並行度,BR 客戶端會 並行地 所有 TiKV 傳送這些 Range 上的備份請求。

當然,備份不可能一帆風順。我們在備份的時候不可避免地會遇到問題:例如網路錯誤,或者觸發了 TiKV 的限流措施(Server is Busy),或者 Key is Locked,這時候,我們必須縮小這些 range,重新發送請求(否則,我們就要重複一遍之前已經做過的工作)。

在失敗之後,選擇合適的 range 來重發請求的過程,在 BR 中被稱為“細粒度備份(fine-grained backup)”,具體而言:

  1. 在之前的“粗粒度備份”中,BR 客戶端每收到一個 BackupResponse 就會將其中的 [start_key, end_key) 作為一個 range 存入一顆區間樹中(你可以把它想象成一個簡單的 BTreeSet<(Vec<u8>, Vec<u8>)> )。

  2. “粗粒度備份” 遇到任何可重試錯誤都會忽略掉,只是相應的 range 不會存入這顆區間樹中,因此樹中會留下一個 “空洞”,這兩步的虛擬碼如下。

    func Backup(tree RangeTree) {
        // ... 
        for _, resp := range responses {
            if resp.Success {
                tree.Insert(resp.StartKey, resp.EndKey)  
            }
        }
    }
    
    // An example: 
    // When backing up the ange [1, 5).
    // [1, 2), [3, 4) and [4, 5) successed, and [2, 3) failed:
    // The Tree would be like: { [1, 2), [3, 4), [4, 5) }, 
    // and the range [2, 3) became a "hole" in it.
    // 
    // Given the range tree is sorted, it would be easy to 
    // find all holes in O(n) time, where n is the number of ranges.
    
  3. 在 “粗粒度備份” 結束之後,我們遍歷這顆區間樹,找到其中所有 “空洞”,並行地進行 “細粒度備份”:

  • 找到包含該空洞的所有 region。

  • 對他們的 leader 發起 region 相應範圍的 Backup RPC。

  • 成功之後,將對應的 range 放入區間樹中。

4. 在一輪 “細粒度備份” 結束後,如果區間樹中還有空洞,則回到 (3),在超過一定次數的重試失敗之後,報錯並退出。

在上述 “備份” 流程完成之後,BR 會利用 Coprocessor 的介面,向 TiKV 請求執行使用者所指定表的 checksum。

這個 checksum 會在恢復的時候用作參考,同時也會和 TiKV 在備份期間生成的逐檔案的 checksum 進行對比,這個比對的過程叫做 “fast checksum”。

在 “備份” 的過程中,BR 會通過 TiDB 的介面收集 備份的 表結構、備份的時間戳、生成的備份檔案 等資訊,儲存到一個  “backupmeta” 中,這個是恢復時候的重要參考。

TiKV

為了實現資源隔離,減少資源搶佔,backup 相關的任務都執行在一個單獨的執行緒池裡面。這個執行緒池中的執行緒叫做 “bkwkr”(“backup worker” 極其抽象的縮寫)。

在收到 gRPC 備份的請求之後,這個 BackupRequest 會被轉化為一個 Task

而後,TiKV 會利用 Task 中的 start_key end_key 生成一個叫做 “ Progress ” 的結構: 它將會把 Task 中龐大的範圍劃分為多個子範圍,通過:

  1. 掃描範圍內的 Region。

  2. 對於其中當前 TiKV 角色為 Leader 的 Region,將該 Region 的範圍作為 Backup 的子任務下發。

Progress 提供的介面是一個使用 “拉模型” 的介面: forward 隨後,TiKV 建立的各個 Backup Worker 將會去並行地呼叫這個介面,獲得一組待備份的 Region,然後執行以下三個步驟:

  1. 對於這些 Region,Backup Worker 將會通過  RaftKV 介面,進行一次 Raft 的讀流程,最終獲得對應 Region 在 Backup TS 的一個 Snapshot。(Get Snapshot)

  2. 對於這個 Snapshot,Backup Worker 會通過 MVCC Read 的流程去掃描 backup_ts 的一致版本。這裡我們會掃描出 Percolator 的事務,為了恢復方便,我們會準備 “default” 和 “write” 兩個臨時緩衝區,分別對應 TiKV Percolator 實現中的 Default CF 和 Write CF。(Scan)

  3. 然後,我們會先將掃描出來的事務中兩個 CF 的 Raw Key 刷入對應緩衝區中,在整個 Region 備份完成(或者有些 Region 實在過大,那麼會在途中切分備份檔案)之後,再將這兩個檔案儲存到外部儲存中,記錄它們對應的範圍和大小等等,最後返回一個 BackupResponse 給 BR。(Save)

為了保證檔名的唯一性,備份的檔名會包括當前 TiKV 的 store ID、備份的 region ID、start key 的雜湊、CF 名稱。

備份檔案使用 RocksDB 的 Block Based SST 格式:它的優勢是,原生支援檔案級別的 checksum 和壓縮,同時具備可以在恢復的時候快速被 ingest 的潛力。

外部儲存是為了適配多種備份目標而存在的通用儲存抽象:有些類似於 Linux 中的 VFS,不過簡化了非常多:僅僅支援簡單的儲存和下載整個檔案的操作。它目前對主流的雲盤都做了適配,並且支援以 URL 的形式序列化和反序列化。例如,使用 s3://some-bucket/some-folder ,可以指定備份到 S3 雲盤上的 some-bucket 之下的 some-folder 目錄中。

BR 的挑戰和優化

通過以上的基本流程,BR 的基本鏈路已經可以跑通了:類似於運算元下推,BR 將備份任務下推到了 TiKV,這樣可以合理利用 TiKV 的資源,實現分散式備份的效果。

在這個過程中,我們遇到了許多挑戰,在這一節,我們來談談這些挑戰。

BackupMeta 和 OOM

前文中提到,BackupMeta 儲存了備份的所有元資訊:包括表結構、所有備份檔案的索引等等。想象一下你有一個足夠大的叢集:比如說,十萬張表,總共可能有數十 TB 的資料,每張表可能還有若干索引。

如此最終可能產生數百萬的檔案:在這個時候,BackupMeta 可能會達到數 GB 之大;另一方面,由於 protocol buffer 的特性,我們可能不得不讀出整個檔案才能將其序列化為 Go 語言的物件,由此峰值記憶體佔用又多一倍。在一些極端環境下,會存在 OOM 的可能性。

為了緩解這個問題,我們設計了一種分層的 BackupMeta 格式,簡單來講,就是將 BackupMeta 拆分成索引檔案和資料檔案兩部分,類似於 B+ 樹的結構:

具體來講,我們會在 BackupMeta 中加上這些 Fields,分別指向對應的 “B+ 樹” 的根節點:

message BackupMeta {
// Some fields omitted...
// An index to files contains data files.
MetaFile file_index = 13;
// An index to files contains Schemas.
MetaFile schema_index = 14;
// An index to files contains RawRanges.
MetaFile raw_range_index = 15;
// An index to files contains DDLs.
MetaFile ddl_indexes = 16;
}

MetaFile 就是這顆 “B+ 樹” 的節點:

// MetaFile describes a multi-level index of data used in backup.
message MetaFile {
// A set of files that contains a MetaFile.
// It is used as a multi-level index.
repeated File meta_files = 1;

// A set of files that contains user data.
repeated File data_files = 2;
// A set of files that contains Schemas.
repeated Schema schemas = 3;
// A set of files that contains RawRanges.
repeated RawRange raw_ranges = 4;
// A set of files that contains DDLs.
repeated bytes ddls = 5;
}

它可能有兩種形態:一是承載著對應資料的 “葉子節點”(後四個 field 被填上相應的資料),也可以通過  meta_files 將自身指向下一個節點: File 是一個到外部儲存中其他檔案的引用,包含檔名等等基礎資訊。

目前的實現中,為了迴避真正實現類似 B 樹的分裂、合併操作的複雜性,我們僅僅使用了一級索引,將的表結構和檔案的元資料分別儲存到一個個 128M 的小檔案中,如此已經足夠迴避 BackupMeta 帶來的 OOM 問題了。

GC, GC never changes

在備份掃描的整個過程中,因為時間跨度較長,必然會受到 GC 的影響。

不僅僅是 BR,別的生態工具也會遇到 GC 的問題:例如,TiCDC 需要增量掃描,如果初始版本已經被 GC 掉,那麼就無法同步一致的資料。

過去我們的解決方案一般是讓使用者手動調大 GC Lifetime,但是這往往會造成 “初見殺” 的效果:使用者開開心心備份,然後去做其他事情,幾個小時後發現備份因為 GC 而失敗了……

這會非常影響使用者的心情:為了讓使用者能更加開心地使用各種生態工具,PD 提供了一個叫做 “Service GC Safepoint” 的功能。各個服務可以通過 PD 上的介面,設定一個 “Safepoint”,TiDB 會保證在 Safepoint 指定的時間點之後,所有歷史版本都不會被 GC。為了防止 BR 在意外退出之後導致叢集無法正常 GC,這個 Safepoint 還會存在一個 TTL:在指定時間之後若是沒有重新整理,則 PD 會移除這個 Service Safe Point。

對於 BR 而言,只需要將這個 Safepoint 設定為 Backup TS 即可,作為參考,這個 Safepoint 會被命名為 “br-”,並且有五分鐘的 TTL。

備份壓縮

在全速備份的時候,備份的流量可能相當大:具體可以看看開頭 “秀肌肉” 文章相關的部分。

如果你願意使用足夠多的核心去備份,那麼可能很快就會到達網絡卡的瓶頸(例如,如果不經壓縮,千兆網絡卡大約只需要 4 個核心就會被打滿。),為了避免網絡卡成為瓶頸,我們在備份的時候引入了壓縮。

我們複用了 RocksDB Block Based Table Format 中提供的壓縮功能:預設會使用 zstd 壓縮。壓縮會增大 CPU 的佔用率,但是可以減少網絡卡的負載,在網絡卡成為瓶頸的時候,可以顯著提升備份的速度。

限流與隔離

為了減少對其他任務的影響,如前文所說,所有的備份請求都會在單獨的執行緒池中執行。

但是即便如此,如果備份消耗了太多的 CPU,不可避免地會對叢集中其它負載造成影響:主要的原因是 BR 會佔用大量 CPU,影響其它任務的排程;另一方面則是 BR 會大量讀盤,影響寫任務刷盤的速度。

為了減少資源的使用,BR 提供了一個限流機制。當用戶帶有 --ratelimit 引數啟動 BR 的時候,TiKV 側的第三步 “Save”,將會被限流,與此同時也會限制之前步驟的流量。

這裡需要注意一個點:備份資料的大小往往會遠遠小於叢集的實際空間佔用。原因是備份只會備份單副本、單 MVCC 版本的資料。通過 ratelimit 限流施加於 Save 階段,因此是限制寫備份資料的速度。

在 “服務端” 側,也可以通過調節執行緒池的大小來限流,這個引數叫做  backup.num-thread ,考慮到我們允許使用者側限流,它的預設值非常高: 是全部 CPU 的 75%。 如果需要在服務側進行更加徹底的限流,可以修改這個引數。 作為參考,一塊 Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz CPU 每個核心大概每秒能生成 10M 經 zstd 壓縮的 SST 檔案。

總結

通過 Service Safe Point,我們解決了手動調節 GC 帶來的 “難用” 的問題。

通過新設計的 BackupMeta,我們解決了海量表場景的 OOM 問題。

通過備份壓縮、限流等措施,我們讓 BR 對叢集影響更小、速度更快(即便二者可能無法兼得)。

總體上而言, BR 是在 “物理備份” 和 “邏輯備份” 之間的 “第三條路” :相對於 mydumper 或者 dumpling 等工具,它消解了 SQL 層的額外代價;相對於在分散式系統中尋找物理層的一致性快照,它易於實現且更加靈巧。對於目前階段而言,是適宜於 TiDB 的容災備份解決方案。

:bulb: Tip: 上文劃線部分均有跳轉,由於微信外鏈限制,大家可以點選尾部 【閱讀原文】 檢視原文