大話Qunar數據庫備份恢復

　　互聯網企業級數據庫的 HA 可用水平分成幾個等級，如下：

　　目前我們 Qunar 數據庫提供99.99%服務，即全年的宕機不可服務時間要控制在53分鐘以內，這對 DBA 來說是個挑戰，我們需要通過 MySQL 的高可用架構設計來達到，當然也需要針對數據庫進行備份。

　　Qunar 的 MySQL 高可用架構有 MMM，PXC 和 QMHA，其中 PXC 和 QMHA 是自主開發設計的架構，對外提供 namespace 服務，在強一致性、性能和跨機房服務間做權衡。

　　常用的數據庫有熱備份和冷備份，熱備份又分為物理熱備份和邏輯熱備份，各種備份方式都有優缺點，企業需要根據自身的服務特點和需要進行選擇。互聯網企業一般都選擇熱備份，Qunar 也是。

　　備份恢復方式

　　優點

　　缺點

　　熱備份(online backup)

　　物理熱備(InnoDB ibbackup、Percona XtraBackup)

　　速度快

　　MySQL版本綁定

　　邏輯熱備(mysqldump、mysqlpump)

　　簡單、備份樣式可選

　　sql語句,備份恢復速度慢

　　冷備份(offline backup)

　　操作簡單、拷貝數據文件

　　a.DB服務中斷業務受損

　　b.無法解決數據空洞問題

　　c.冷備恢復存在系統版本文件大小寫敏感和浮點數格式等問題

　　Qunar 利用的是 Percona 公司的 Xtrabackup 產品，進行封裝和自定義一些其他功能，我們就要講講 Qunar 熱備份的特點。

　　各個互聯網公司在備份方式都有這樣那樣的問題。

　　1本地存儲備份

　　這種備份方式占用本地磁盤空間和 IO，磁盤消耗大，比如數據庫500GB，那備份也要占用500GB，這樣磁盤容量就要翻倍，這是一種浪費。恢復時也要將備份集傳輸到對應機器上，這樣會占用線上數據庫服務器的網絡帶寬，會影響數據庫的正常業務訪問。

　　2備份方式選擇

　　有些公司的備份種類繁多，不容易管理維護。

　　3非集中管理

　　DBA 部署之后不知道哪個集群有備份，哪個集群沒有備份，備份類型是啥，這些都不利于維護管理，有可能會造成很嚴重的問題。

　　4備份文件校驗

　　很多公司就是每次備份完成就認為萬事大吉了，但剛做的備份真的有用嗎，如果恢復時無法使用怎么辦。對于數據庫備份集的校驗是必不可少的。

　　5備份節點選擇

　　有些公司剛開始會在 slave 節點上部署備份，但 master-slave 發生切換后備份節點就變成了 master，這樣會對業務使用產生影響，比如磁盤 IO 和帶寬，這時很多公司都是手動選擇新的備份節點，將原備份刪除，很麻煩而且還容易遺忘。6流量控制

　　流量控制不好，會導致同一個機器上多個數據庫同時備份。我們現在都是單機多實例，如果這些實例同時備份就會對數據庫業務產生影響，所以這也是需要解決的問題之一。

　　7備份時間過長

　　由于數據庫太大，導致備份和恢復時間變長，故障的時間也響應的變長。當然備份過程中備份程序被阻塞也會使備份時間變長，比如備份時有一個長查詢阻塞了 FTWRL 的執行，這樣我們需要解決阻塞的問題。備份時數據文件寫入的磁盤和網絡太慢也會導致備份時間延長。

　　好了，說了這么多備份恢復容易出現的問題，Qunar 是怎么做的呢？

　　Qunar 備份在每個機房都有一個 backup 角色的機器，用于存儲本機房內 MySQL 數據庫的備份，然后再傳輸到遠端的備份池 MFS。如圖：

　　針對單個機房的備份就是，備份節點執行備份，流方式傳輸到本機房的 backup 上，然后再根據備份策略將過期的備份集傳輸到 MFS 備份池，這樣就解決了本地存儲備份集的磁盤容量問題。如圖：

　　Qunar 的備份任務會采用專用的備份網卡，這樣不影響業務訪問數據庫，且同一個備份節點上的實例不會同時進行備份，備份任務都是獨立的。如圖：

　　在 DBA 的 DUBAI 管理平臺上管理各個實例的備份情況，包括備份開始時間，結束時間，備份策略，保留方案，備份節點，上次備份時間，是否成功等信息。備份任務由后端程序統一調度分配，備份程序不使用 agent 或者 crontab 的方式，故備份程序都是一致的且容易管理。如圖：

　　每次備份完成后都會對備份集做一致性恢復，確保備份集文件可用。如圖：

　　下面是 Qunar 備份整體的任務流程圖。

　　綜上，Qunar 的備份有如下特點：

　　1、封裝 Percona Xtranbackup 全量備份。

　　2、binlog 備份作為增量備份，且 binlog 備份節點與熱備份節點同步選擇，可以保證增量可用。

　　3、流備份——stream=tar，本機不保留備份集。

　　4、遠程存儲備份集，backup 角色機器，以及遠端 MFS 存儲。

　　5、自動選擇備份節點，standby 或者 statistic，無視主從切換。

　　6、獨立的備份網卡，不占業務帶寬。

　　7、備份完成即一致性恢復，保證備份集邏輯上可用，備份集處于一致性狀態。

　　8、MFS多副本模式，保證備份集物理損壞仍然可用。

　　9、集中式后臺管理、調度，并發可控，狀態監測，拋棄了 agent 和 crontab。

　　各個實例備份任務執行情況。如圖：

　　添加備份任務。如圖：

　　單個集群的備份詳情和備份集信息。如圖：

　　自動化恢復，根據需要填寫要恢復的集群和目標機。如圖：

　　好了，到此 Qunar 的備份恢復都講述完了，當然我們也有一些需要完善的地方，包括 binlog 的恢復，這樣可以自動化做到基于時間點的恢復。不過我們已經解決了很多公司遇到的備份恢復問題，希望大家有更好的建議和意見來與我們溝通，謝謝大家！

　　公告通知

　　一場 React Native 技術大會即將舉辦，歡迎參加！

　　《YMFE Conf 2017: React Native 應用與實踐技術大會》 將會于十月中旬在北京舉辦，屆時將有各知名互聯網公司移動前端技術達人們來分享交流 React Native 在各自公司的應用與實踐。大會門票目前正在火熱開售中，掃描下方二維碼瀏覽YMFE CONF官網并購票。

　　掃碼瀏覽 YMFE CONF 官網

　　掃碼購買 YMFE CONF 門票