介紹

Uber 利用存儲技術來運行其實時業務。這包括將在線數據存儲在開源數據庫中，例如 MySQL、 Apache Cassandra 、etcd和Apache Zookeeper ，以及 Uber 自研的存儲解決方案，例如托管在Uber 有狀態平臺上的Docstore 和 Schemaless。數據庫備份恢復對于 Uber 的業務連續性和災難恢復至關重要。它支持多種用例，例如緩解業務中斷、從數據損壞中恢復以及取證和合規性。此外，它還支持模擬生產環境，用于負載測試、數據完整性和安全性測試。

Uber 的在線存儲解決方案擁有數十 PB 的數據容量，用于支持關鍵業務運營。這些解決方案每秒可處理數百萬至數十億次請求，覆蓋 Uber 的全球各個業務領域。如此龐大的規模使得 Uber 能夠以不同的時間間隔從數據庫中備份近 100 PB 的數據，TB 級到 PB 級的數據可以在幾分鐘到幾小時內恢復。 

這篇博客介紹了 Uber 針對在線數據庫開發的強大備份恢復系統的最新進展。

挑戰

大規模改進 Uber 的備份恢復系統面臨諸多挑戰：

• 原始的備份調度：以前，備份的調度方式很簡單，就是周期性地盡力執行備份。這種方式沒有考慮當前的網絡資源、主機資源、優先級、速率限制或系統可觀測性。這導致備份工作負載利用率出現峰值波動，引發多種問題，需要緩慢的機制來恢復備份。
• 臨時恢復流程：恢復流程沒有系統性地定義，而是以未經檢查的腳本或過時的運行手冊的形式存在。隨著數據庫系統定期升級，該流程很容易失效。
• 缺乏恢復演練：沒有定義恢復流程或系統工作負載。此外，也沒有定期演練來驗證恢復功能是否正常。 
• 新的恢復目標：過去，某些技術的恢復點目標 (RPO) 為 7-21 天，而恢復時間目標 (RTO) 對于大型數據庫而言則從未知到數天不等。隨著調度層、各種基礎架構層以及特定技術備份和恢復流程的多項優化，大多數數據庫已轉向需要可靠的備份。RPO 已縮短至 4-24 小時，RTO 已縮短至每小時 300 TB。 

這篇博客介紹了我們為應對這些挑戰而實施的一些優化措施。

架構

Uber 有狀態平臺之上的增強型備份恢復系統，通過抽象化管理備份恢復生態系統及其底層組件的各個方面，提供統一的體驗。這些方面包括針對整個有狀態數據庫集群的備份工作負載進行集中式自適應調度。每個備份工作負載都會備份當前數據庫快照，并進行整體狀態傳播，同時監控備份過程。在恢復方面，系統會定期進行恢復測試，以驗證現有備份與底層恢復自動化流程的完整性和正確性。總而言之，這構建了CBCR（持續備份持續恢復）框架的概念。

備份恢復系統采用基于快照的備份和恢復架構來管理有狀態集群，從而提高災難恢復能力。 

圖 1：有狀態集群的連續備份恢復

備份恢復系統包含以下組件：

• 持續備份：一個集中式協調器，用于定期在有狀態技術中調度備份，并可配置數據庫備份策略。這能夠自適應地分散備份工作負載，從而確保網絡可靠性和安全性。
• 持續恢復：一個集中式協調器，用于定期測試跨有狀態技術的恢復操作，并可配置數據庫恢復策略。它通過驗證備份快照的正確性和完整性，確保恢復工作負載的健康運行。
• 備份框架：一個統一的備份驅動程序，集成了存儲數據庫特定的插件，以執行數據庫快照邏輯并上傳到 Uber 的 blob 存儲。 
• 恢復框架：統一的恢復驅動程序集成了存儲數據庫特定的插件，以執行備份下載和將快照加載到數據庫。 
• 技術主流工作負載：任何有狀態技術都包含主流組件，例如技術管理器/工作節點、數據庫工作負載以及其他對業務運營至關重要的輔助工作負載。管理器/工作節點負責協調并遵循目標狀態驅動的架構。 
• Uber Blobstore：一個專為大規模上傳/下載而構建的對象存儲后端，具有可配置的策略。它可作為多種云存儲選項之上的虛擬化層。

持續備份

持續備份功能可對所有數據庫進行持續可靠的備份。它既能以足夠的頻率進行備份，又能降低存儲成本和網絡利用率。 

Time Machine是持續備份框架的關鍵組件，它作為集中式備份協調器，運行著全局自適應調度器，定期觸發備份工作負載。該系統每天至少上傳數 PB 的數據。Uber 的網絡帶寬在多個 Uber 關鍵業務工作負載的在線/離線流程中共享。Time Machine 解決了如何在不中斷服務堆棧網絡使用的情況下自適應地調度備份的難題。 

Time Machine 擁有一個最優選擇引擎，內置客戶端速率限制功能，用于決定在給定的調度周期內備份哪些數據庫。它會考慮多種信號，例如：

• 備份新鮮度標準
• 動態網絡和主機基礎設施可用性 
• 備份消耗的歷史趨勢 
• 企業高峰/低谷網絡利用率
• 根據存儲技術制定備份速率限制策略，優先備份關鍵數據庫
• 地理位置、其可用性和利用率

這種智能調度機制能夠高效、均勻地大規模分配整個數據庫備份任務。在做出最優選擇后，Time Machine 會調用特定于數據庫的觸發器來啟動運行時備份工作負載，從而提供可靠的備份、完整性和保護。

圖 2：有狀態平臺上的持續備份

備份過程遵循以下步驟： 

• 持續備份（或時間機器）有一個全局調度程序模塊，該模塊會定期運行以調度備份工作負載。
• 備份調度程序在每個周期內調用 3 個連續階段：發現、選擇和觸發。

• 發現階段會對整個有狀態存儲集群進行全集群掃描，以收集所有可能的數據庫進行備份。 
• 選擇階段應用決策標準（多項篩選和排序規則）來確定最終需要備份的數據庫集合。這使得該過程能夠適應網絡和主機基礎設施的可靠性。 
• 觸發階段決定備份模式（完整備份或增量備份），并根據特定技術的行為調用備份工作負載。

• 技術插件接口是針對每種存儲技術定義的，用于執行持續備份階段所需的各種操作。這些操作包括數據庫級元數據、備份歷史記錄、正在運行的備份工作負載以及當前集群狀態。
• 對于每個備份觸發事件，由Uber 有狀態平臺支持的相應技術特定的管理器/工作進程會協調整個備份工作負載。它支持按需生成備份邊車工作負載，并共享期望狀態。然后，它會驗證備份的完整性，并將實際狀態發布到有狀態元數據存儲中。 
• 對于任何存儲技術，每個備份工作負載都會執行數據庫快照邏輯并上傳到 Uber 的 blob 存儲。

備份框架 

圖 3：備份框架控制流程

Backup框架是一個通用備份驅動程序，集成了特定技術的插件，用于執行數據庫快照邏輯，并高效可靠地上傳到 Uber 的 Blob 存儲。運行時備份工作負載作為按需 sidecar 容器運行，與主流容器（例如技術節點工作容器和數據庫容器）并行運行。節點是運行在由主機集群支持的容器化 cgroup 中的有狀態工作負載單元，遵循目標狀態驅動架構。 

以下是備份流程： 

• 對于任何數據庫，節點工作進程都作為主要工作負載，負責數據庫的編排和健康維護。它將傳入備份的目標狀態作為運行時備份工作負載的輸入，并監控備份的整個生命周期。
• 備份驅動程序負責協調數據庫快照文件的提取和備份。它以增量方式上傳這些文件，并進行速率限制和數據完整性檢查，同時將上傳文件的狀態記錄到備份索引中。上傳完成后，它會清理這些文件，以避免磁盤使用量激增。
• 備份驅動程序還會將備份索引推送到 Blob 存儲，這有助于對快照版本之間的不可變文件進行去重，從而構建增量/差異備份。它會引用所有文件，形成邏輯上完整的備份。
• 備份驅動程序監控鉤子會在節點資源被高度利用時終止進程，以避免中斷生產流量。
• 備份驅動程序完成，通過備份 I/O 卷將實際狀態共享回工作進程，最終同步回有狀態元數據存儲。

以下是每種技術的數據庫快照邏輯工作原理：

• 基于 MySQL 的存儲技術使用Percona Xtrabackup快照工具包。這包括 MySQL和Uber 自研的 Docstore/Schemaless 技術，并提供定制化的高效差異備份解決方案。 
• Cassandra 使用類似Medusa 的差異備份設置，并使用 nodetool 快照工具包。 
• etcd 使用etcd-clientv3來獲取時間點快照。 
• Zookeeper 會備份最新的 snapshot.<zxid>文件。

恢復框架

恢復框架與備份框架類似，采用技術無關的設計，旨在實現自動化和一致的恢復。其模塊化設計使其具有可擴展性，并能適應不同的數據庫架構。此外，該框架無需人工干預，縮短了恢復時間，并最大限度地降低了就地恢復和異地恢復場景中人為錯誤的風險。

該框架提供了一個通用驅動程序，并帶有可擴展的、特定于數據庫技術的插件，用于定義關鍵組件。清單提供程序插件經過定制，可獲取如上所述的特定于數據庫的備份索引清單，其中每個備份都與一個詳細的備份索引相關聯。備份索引引用來自不同備份類型（完整備份、增量備份或差異備份）的所有快照文件以及恢復期間所需的文件。數據庫加載程序定義了針對數據庫架構（MySQL、Cassandra、etcd）定制的數據庫導入邏輯，以使數據庫達到可用狀態。

以下是每種技術的數據庫加載過程：

• 基于 MySQL 的恢復過程使用 Percona XtraBackup 等工具提取和準備備份，以便 MySQL 可以使用正確的數據和設置順利啟動。
• Cassandra 恢復操作包括下載備份文件（通常是 SSTable），并將其加載到 Cassandra 引擎中。
• etcd/Zookeeper 恢復過程類似，即將備份快照放入其指定的數據庫目錄中，并利用其特定的快照加載器庫。

圖 4：恢復框架控制流

Restore 框架與 Continuous Restore 框架的集成有助于持續驗證并為真實世界的情況做好準備。

持續恢復

持續恢復框架通過頻繁驗證已恢復的備份來確保數據的完整性和正確性。該框架提供智能調度功能，可配置恢復測試節奏，從而實現定期和臨時驗證。調度邏輯會考慮硬件資源可用性，以避免對生產環境造成影響。 

恢復測試策略包括專用數據庫測試和隨機數據庫測試。專用測試使用預定義的、包含已知數據的數據庫，執行詳細的端到端恢復和驗證。隨機測試則選擇具有特定特征的生產規模數據庫，以便在真實環境下更廣泛地驗證恢復工作流程。

恢復后，該框架會執行強大的數據驗證，包括文件完整性驗證和針對已知專用數據庫的逐字節數據比較。此外，該框架還會收集詳細的分析數據，包括恢復成功率、基于備份數據的恢復率、數據完整性驗證結果以及多個性能指標，并將這些數據報告給監控和分析部門。

修復評估過程分為四個階段：

• 發現/選擇：根據層級、大小和上次成功備份時間等標準，識別符合恢復測試條件的數據庫。應用過濾和優先級規則來確定要恢復的數據庫，從而實現工作負載的均衡分配。此外，該過程還考慮了恢復評估策略（專用或隨機），從而為評估框架提供了靈活性。
• 觸發階段：通過創建臨時集群進行測試來執行恢復過程。它會設置一個新集群并觸發恢復，利用可擴展恢復框架。此階段充當被測系統，負責從備份中執行實際的恢復操作。
• 驗證：根據恢復評估策略運行驗證。對于專用數據庫，將數據與預定義的數據集進行比較。對于隨機數據庫，驗證備份完整性。
• 報告：測試完成后，系統會生成詳細報告，并清理測試過程中創建的任何臨時資源。

圖 5：有狀態集群中的持續恢復框架

持續恢復框架的優勢包括： 

• 運行彈性：系統具備恢復能力，降低了停機風險。
• 合規和審計支持：生成自動報告以滿足回收和合規要求。
• 數據保障：驗證數據完整性和恢復過程，以提高可靠性。
• 可操作的見解：提供恢復性能的可見性，并突出顯示潛在的改進領域。

通過不斷驗證恢復流程，我們的框架加強了災難恢復準備工作，保護了關鍵數據，并增強了系統大規模恢復能力。

作者丨Uber Backend      編譯丨Rio

來源丨網址：https://www.uber.com/blog/robust-database-backup-recovery-at-uber/?uclick_id=1710c187-26ed-4c1b-9134-278f616291e7