資料庫作為基礎設施，其安全性不言而明，是以資料安全備份和恢複功能是在嚴肅使用場景下的标配。TiDB 作為一款分布式資料庫，目前可以滿足超大叢集的備份恢複的需求，經過測試，10T 資料的備份恢複速度可以達到 GB/s 級别。這得益于我們研發的分布式備份恢複工具 Backup&Restore That Scales(以下簡稱 BR)。
如果你業務産生海量資料，并極度重視資料安全、備份恢複的效率，那麼 TiDB + BR 值得一試，從此再也不怕“删庫跑路、恢複緩慢”。
一個 10T 叢集的測試
讓我們先來秀一下肌肉吧！我們使用 BR 備份恢複了一個 10T 資料量的超大叢集 [1] ：
- 備份速度：548MB/s * TiKV 節點數；
- 恢複速度：150MB/s * TiKV 節點數。
光說這兩個數字可能不直覺，是以我們特地把真實發生的備份恢複過程截了圖：
備份
圖檔說明：
- 我們備份了兩張表，綠線是整體的備份速度，其餘線條是各個 TiKV 節點備份速度。
- 11:15 和 11:28 在備份索引資料，由于索引資料内容較短，是以備份速度有些下降。
恢複
圖檔說明：
- 我們恢複了之前備份下來的兩張表，同樣的，綠線是整體速度，其他線條為各個 TiKV 節點恢複速度。
- 恢複期間的毛刺是因為我們将恢複任務拆分成一個個小任務，各個小任務之間串行執行(潛在優化點)。1:00 和 1:15 恢複速度下降同樣也是由于索引内容較短導緻。
分布式資料庫備份恢複的難點
備份恢複一直是超大 TiDB 叢集的難題：TiDB 存儲層的分布式架構實作沒有一緻的實體快照的概念。 由于 TiDB 相容 MySQL 協定，我們曾經考慮過使用 mydumper/myloader 作為備份恢複工具 (MySQL 社群常用的備份恢複工具) ， 但是 mydumper 面對超大規模的 TiDB 叢集就顯得有些捉襟見肘，不僅無法合理利用叢集資源來提升備份速度，嚴重影響業務的請求，還有一定機率造成 TiDB OOM。 我們曾經也針對 TiDB 優化了類似 myloader 的工具：loader。根據之前的測試 [2] ，loader 恢複 1TB 的資料大概需要 19 個小時。但是這個速度難以滿足我們對恢複性能的追求，主要原因是恢複流程走 SQL，流程長，添加了大量沒必要的計算，導緻資源不能被充分利用。 總之，mydumper 和 loader 雖然能用，但沒有完美契合 TiDB。是以，我們決心開發新的備份恢複工具，BR。
BR 設計與實作
水準擴充
是的，BR 讓備份和恢複能夠水準擴充！ BR 和 mydumper 最大的不同點在于， 它 直接從 TiKV(存儲層)入手 ，“用對的方法做對的事”。BR 将備份和恢複任務下推到各個 TiKV 執行(類似于 Coprocessor 下推)，比如一個備份任務可能跨越了多個 Region，BR 隻需給每個 TiKV 下發一個請求，就能讓各個 TiKV 自行備份它上面的資料。 BR 将備份恢複帶來的 CPU 和 IO 均勻的分散在各個 TiKV 上，輕松備份恢複上百個節點的 TiDB 叢集。
強一緻性
滿足一緻性要求是備份恢複工具的及格線。 Snapshot Isolation 即是 TiDB 所提供的一緻性，也是 BR 的備份恢複所提供的一緻性。 資料分散在多台 TiKV 節點，BR 是如何做到 Snapshot Isolation 呢？其實很簡單，BR 隻需取一個 TiDB 事務的 Timestamp，然後發到所有 TiKV 上。TiKV 将這個 Timestamp 的能看到的資料備份即可，這裡的資料不僅包含了使用者的資料，也包含了 TiDB 的中繼資料，比如 Table schema 等，是以 BR 備份在滿足存儲層(TiKV)一緻性的同時也能滿足 SQL 層(TiDB)的一緻性。
體驗一下？
如果你手頭恰好跑着 TiDB 叢集，叢集資料恰好上了 TB，又苦于沒法快速備份恢複，那麼不妨試試 BR。我們已經陸續更新了一些文檔，供大家參考：
-
BR 使用手冊：
https://pingcap.com/docs-cn/v3.1/reference/tools/br/br/
-
BR 備份與恢複場景示例：
https://pingcap.com/docs-cn/v3.1/reference/tools/br/use-cases/
BR 目前還處于 beta 階段，如果在使用過程中發現了任何問題，歡迎回報到 ： https://github.com/pingcap/br/issues
更多令人期待的新功能
目前 BR 仍在不斷的開發完善中，尤其在去年 PingCAP Q4 Special Week 活動中，富有創造力的 TiDB 社群小夥伴和 PingCAP 工程師為 BR 添了許多令人激動的新功能：
- RawKV backup restorehttps://github.com/pingcap/br/issues/86沒錯，BR 除了支援備份恢複 TiDB 叢集之外，還能支援使用 RawKV 的 TiKV 叢集，其中 TiKV 這邊的 PR 由一位社群小夥伴貢獻——感謝來自一點資訊的 xinhua5！
- Incremental backup restorehttps://github.com/pingcap/br/issues/90增量備份不僅解決了全量備份空間占用的大的問題，也能解決了 TiDB Binlog 損壞期間快速恢複的難題！
-
Backup to common cloud storage
https://github.com/pingcap/br/issues/89
在雲的時代，怎麼能缺少對雲存儲的支援？BR 已經支援将備份儲存到 AWS S3 上，不久也将支援備份到 Google Cloud Storage。
-
Online restore
https://github.com/pingcap/br/issues/87
最初，BR 恢複的定位和 TiDB Lightning 一樣，隻支援離線恢複到全新的叢集。通過這個功能，BR 即将支援線上恢複，這對 OLAP 場景中的導入資料階段非常有幫助。
以上新功能還在加速實作過程中，非常歡迎感興趣的小夥伴們能夠參與進來，一起玩轉 BR 這個炫酷的分布式備份恢複工具，大家有任何新鮮的點子都可以開 Issue 讨論！ 另外，我們也很重視 TiDB 使用者的需求，希望能優先傳遞使用者最需要的功能， 歡迎點選 (投票開放 1 周) ，我們将根據大家的呼聲調整開發優先級～
附：
[1] 五台 Intel® E5-2630v4, Intel® SSD P4510 4TB 實體機，每台部署一個 TiKV，使用本地模式進行備份恢複。備份資料庫邏輯大小 3.34T，三副本實體大小 10.1T。備份并發參數 16，恢複并發參數 128。恢複速度受 Region 排程影響比較大，不包含排程，速度為 279MB/s。
[2] loader 工具的 load 子產品性能測試資料：
https://pingcap.com/docs-cn/stable/benchmark/dm-v1.0-ga/#在-load-處理單元使用不同-pool-size-的性能測試對比