?數據庫備份還原系統

　　編者按：《運維之下》一書覆蓋了系統、網絡、數據庫、安全、標準化、自動化等多個層面，從創業初期見招拆招到BAT級別的規模化運維，從PaaS、IaaS到公有云，從運維理念到平臺實踐，都有所闡述。作者從個人成長經歷出發，分享了自己與團隊在運維工作發展過程中遇到的問題，如何去思考問題，怎樣去解決問題。與其說這是一本傳授管理經驗和工作秘訣的書，不如說它更是一本關于運維體系化的指導手冊。在各種說教式理論類叢書漫天飛的同時，筆者能夠耐得住性子，將自己的多年的從業經驗，合力共聚為一本書，這本書的含金量自然可想而知。本篇為《運維之下》第二十章。

　　第二十一章：數據庫備份還原系統

　　數據是出于用戶對公司產品的喜歡和信任，不斷創造和提交的。對于公司來說，這是無比珍貴的資產。如果不幸把數據損壞或者弄丟了，會嚴重地損害用戶的權益，有可能導致嚴重的用戶流失。讀者可以想象一下，如果facebook的用戶數據一夜之間消失了，用戶會有什么反應呢？如果說對facebook的體驗還不強烈，可以再想象一下，若此時存放著你所有存款的銀行突然告訴你，他們把數據弄丟了，而且沒法復原，你的銀行存款都只能清零，你還能繼續淡定地看下面的文字嗎？

　　相信通過上面的兩個例子你已經理解了數據的重要性，那也就能明白對于整天和數據打交道的DBA來說，數據備份在日常工作中占據了多么重要的位置。對于DBA來說，不怕操作出問題，就怕出問題后沒有備份數據進行修復。對數據的任何操作都有風險，一旦出現誤操作、數據損壞等意料之外的情況，就可以隨時用備份數據把數據恢復到操作前的狀態。而如果需要進行數據修復時，卻無法找到備份數據進行恢復，這種抓狂和絕望，相信大家或多或少都體驗過。

　　為了避免這種虐心的體驗，我們把數據庫備份還原系統的開發工作放到了第一優先級的位置。經過三個主要的版本開發，備份還原系統已經在生產環境中提供自動創建備份任務、定期進行備份、自動數據恢復測試的功能，保障了業務數據100%的備份成功率和備份數據有效性。本章我們就來介紹數據庫備份還原系統的發展過程。

　　為了避免這種虐心的體驗，我們把數據庫備份還原系統的開發工作放到了第一優先級的位置。經過三個主要的版本開發，備份還原系統已經在生產環境中提供自動創建備份任務、定期進行備份、自動數據恢復測試的功能，保障了業務數據100%的備份成功率和備份數據有效性。本章我們就來介紹數據庫備份還原系統的發展過程。

　　單機備份工具

　　我們的第一套備份系統是在每臺服務器上單獨運行一個備份任務，任務管理都是靠DBA手工進行的，或許這個階段稱之為備份工具會更合適。

　　簡單來說，單機備份就是在需要進行數據備份的服務器上安裝一個備份工具，比如MySQL官方自帶的Mysqldump工具，或者第三方開源的產品Mydumper或Xtrabackup，通過crontab等方式調度，備份數據存儲在本地服務器上；需要進行數據恢復時，從存有備份數據的服務器上拷貝一份數據到需要進行恢復的服務器上。

　　單機備份是最簡單的一種方式，靠人工來管理備份任務，并需要定期檢查備份任務運行是否正常。這種方式上手快，門檻低，所需的開發工作量也很少，適合用在數據庫實例比較少、每個實例體量不大的場景下。

　　數據庫集群數量少的時候，單機備份方式還能滿足日常備份需求，但隨著數據規模的擴大，問題就凸現出來了。

　　◎ 備份數據存儲周期不長：畢竟是存儲在本地數據庫服務器上，一般情況下，為了保證數據庫服務的IO能力，磁盤都選用高IO能力、低存儲空間的高轉速SAS盤或者SSD盤，再加上做了RAID，實際可用的存儲空間本來就沒有多少，如果還要存儲幾個周期的備份數據，空間資源捉襟見肘。

　　◎ 容易影響數據庫運行：因為任務運行和數據存儲都與數據庫服務在同一臺服務器上，每次運行備份任務時，都會同時出現大量的磁盤讀/寫操作，容易和數據庫服務爭搶IO資源，影響服務的響應效率；進行數據還原時，拷貝備份數據也會有大量的磁盤讀操作，同樣也會影響到正在運行的數據庫。有的讀者也許會說，可以部署一臺數據庫服務器，專門用來做備份。這樣當然可以，不過本著節約的原則，我們還是不推薦這種方式。想想：當你有幾百上千個集群時，會有幾百上千臺服務器專門用作備份，你說這事怎么給老板解釋？

　　◎ 維護代價高：靠人工維護，不僅容易出錯，而且每次變更調整效率也會有所折扣。另外，由于備份任務零散地分布在多臺服務器上，只能靠人工記錄任務和服務器的對應關系，正確性難以保證，時間一長，容易出現遺漏或錯誤。

　　提高備份系統的自動化程度，加強對備份任務的管理，減少DBA在備份管理上的時間投入，這是我們開發第二版備份管理系統的出發點。

　　集中管理備份系統

　　為了便于統一管理和調度備份任務，我們設計了任務管理模塊，把所有備份任務的信息都進行集中記錄和維護。管理模塊主要有三個功能。

　　◎ 任務管理：所有的備份任務管理都由任務管理模塊負責，可以添加、刪除、修改備份任務，或者激活、停止某個任務的運行，并記錄每一次任務運行的狀態，比如什么時候在哪臺數據庫上啟動了備份程序，備份過程運行了多長時間，備份策略是全量還是增量，運行結果是否正常，如果正常，備份數據占用了多少空間等，所有信息一目了然，便于DBA每天對備份任務進行常規檢查。

　　◎ 任務調度：通過時間事件來調度備份任務。當時間事件觸發某個備份任務開始運行以后，管理程序先在本機開啟一個TCP端口，用于接收客戶端發回的備份數據；然后遠程調用部署在MySQL服務器上的備份執行程序，執行程序通過Xtrabackup開始數據拷貝，并將備份數據通過流式（stream）發回到備份服務器集中存儲。在備份過程中，只有一次數據讀取操作，不在MySQL服務器上再次寫入數據，減少了對IO的影響。

　　◎ 數據存儲：所有的備份數據都通過網絡傳回管理模塊所在的服務器統一存儲，便于進行查找和管理。

　　同時我們設計了任務執行模塊，主要負責實施備份操作，完成管理模塊發送過來的備份任務，并將備份出來的數據發送給管理模塊。如果在執行過程中出現任何錯誤，執行模塊還會將錯誤信息的上下文反饋給管理模塊，并停止任務運行。對現有開源的備份工具進行比對并結合生產環境情況綜合評估以后，我們選擇了Percona Xtrabackup作為基礎備份工具。Xtrabackup可以實現InnoDB表的無鎖在線備份，降低了備份任務對數據庫正常運行的影響。Xtrabackup是執行模塊的重要組成部分。

　　集中管理備份系統的結構示意圖

　　集中化管理可以有效地提高DBA的工作效率，對備份任務的管理（增、刪、改、查）只需要在頁面上用鼠標點擊幾下就可以完成，每天的備份任務運行情況也一目了然。這種方式具有開發量小、管理直觀快捷的優點，特別適合用在中等規模的數據庫集群中。用戶可以通過Web管理頁面查看和管理所有的備份任務，如圖所示。

　　備份任務管理

　　備份任務運行報表

　　隨著數據規模的繼續增長，這套系統也逐漸難以滿足需求，下面是暴露出來的主要問題。

　　◎ 存儲空間飽和：由于所有的備份數據都要傳回存儲模塊進行存儲，在備份任務數量增多的同時，存儲空間的爭搶問題變得愈加嚴重。

　　◎ 并發控制不便：由于備份任務是通過時間事件進行觸發的，有可能出現在部分時間區間大量的備份任務一起運行，備份存儲服務器的IO壓力非常大；而有些時段又沒有備份任務運行，資源白白浪費掉了。

　　◎ 無法進行水平擴展：為了便于在備份過程中就將備份數據傳回存儲模塊進行存儲，任務管理模塊和存儲模塊是整合在一起的，導致了嚴重的中心化，要擴展存儲模塊非常麻煩。

　　細心的讀者可能會發現，由于任務管理模塊和調度模塊是整合在一起的，而調度模塊和存儲模塊又相互依賴，管理模塊的中心化導致了后面兩個模塊無法做到水平擴展，而出現瓶頸的主要是調度模塊和存儲模塊。如果能把任務管理模塊解耦，設計成獨立的一個部分，就可以對后兩個模塊進行擴容了。基于這個思路，我們對第二版備份系統進行了改版，把任務管理模塊和調度模塊分拆為兩個獨立部分，并引入了優先級隊列，去除了時間事件驅動的方式，形成了第三版備份管理系統——分布調度備份系統。

　　分布調度備份系統

　　第三版備份系統由三層邏輯組成，第一層是任務管理模塊（Task Manager），和第二版的任務管理模塊功能類似，用于管理所有的備份任務和記錄元信息；主要的改變就是增加了一個優先級隊列。每個備份周期開始時（如每天零時），管理模塊會根據現有的所有處于激活狀態的任務的重要程度，生成一個備份任務優先級隊列，然后等待處于第二層的調度模塊來請求任務。

　　調度模塊（Scheduler）的調度策略和第二版不同，放棄了時間事件觸發的方式，而是采用了自發請求任務的方式。如果調度模塊發現當前自己正在運行的任務數N，小于允許運行的最大任務數M，即N

　　執行模塊的功能和第二版相同，只負責執行具體的備份操作，沒有任何變化。

　　分布調度備份系統的三層結構示意圖如圖21-4所示。用戶可以繼續通過Web頁面管理和查看備份任務，也可以通過API的方式和管理模塊進行交互。

　　分布調度備份系統的三層結構示意圖

　　第三版備份系統的主要特點如下：

　　◎ 任務管理集中化：所有的任務依然是集中管理，通過Web頁面或者API的方式，可以管理和查詢所有任務的信息和歷史運行狀態。

　　◎ 有效的并發控制：每個調度模塊都可以根據服務器的配置，調配允許同時運行的任務數，使備份服務器的壓力可控。

　　◎ 方便水平擴展：如果磁盤存儲空間不足，則可以通過增加服務器的方式快速擴容，新增加的服務器可以自動注冊到任務管理模塊中，并申請任務運行，管理代價很小。

　　◎ 數據分布存儲：備份任務是隨機在不同的調度模塊（存儲服務器）上運行的，每個備份任務的備份數據都會分布在多臺服務器上，如果其中一臺存儲服務器掛掉了，損失的也只是一部分備份任務的某幾次備份數據，不會出現某個任務的全部備份數據丟失的情況。

　　◎ binlog備份：前面介紹的備份都是某個時間點的數據鏡像，如果需要恢復到任意時間點，就需要使用binlog。在第三版備份系統中，支持binlog備份的需求。當用戶添加了一個日常備份任務以后，備份系統通過獲取數據庫實例的復制信息（Slave status），找到當前實例的上級主庫（或者主庫就是該實例自身），然后在備份服務器上啟動一個程序，模擬成數據庫從庫，向主庫實時同步binlog任務，達到更新數據實時備份的目的。

　　◎ 自動數據還原：由于任務管理模塊記錄了所有備份數據的信息，這些信息就可以用來實現自動還原。自動還原過程類似于備份過程，只不過數據傳輸方向是相反的。當用戶發起一次數據還原請求時，備份系統會找到一份符合條件的備份數據，并將數據發送給需要恢復的目標服務器，進行恢復操作，如果有需要，還可以自動建立新實例和主庫的復制關系，完成數據恢復過程。另外，結合binlog備份，可以恢復數據到任意時間點，供DBA或者研發人員分析、測試使用。

　　◎ 自動恢復測試：備份系統會周期性地對備份數據進行恢復測試，檢驗備份數據的可用性和正確性，如果發現異常，會及時通知相關的負責人員。對備份數據定期進行恢復測試，可以有效地保證備份數據的正確性和有效性，確保在需要的時候能有一份可用的數據副本。

　　總結

　　本章介紹了數據庫備份還原系統發展的主要歷程和現狀。備份還原系統共經歷了三個大版本的發展，從最初的單機備份，發展到目前在役的分布調度備份還原系統，實現了備份管理自動化、任務調度自動化和可擴展、數據恢復測試自動化等重要功能。在保證數據備份覆蓋率和成功率的同時，有效地提高了DBA的工作效率，減少了人工操作的時間投入和誤（漏）操作的數量。

　　更多精彩內容技術頭條將持續跟進，第一時間為大家送上最新動態~o(^▽^)o

　　請掃描以下二維碼關注技術頭條公眾號更多精彩內容將在技術頭條持續發布，敬請關注！微信號：jishutoutiao