大話Qunar數(shù)據(jù)庫備份恢復(fù)

　　互聯(lián)網(wǎng)企業(yè)級數(shù)據(jù)庫的 HA 可用水平分成幾個等級，如下：

　　目前我們 Qunar 數(shù)據(jù)庫提供99.99%服務(wù)，即全年的宕機不可服務(wù)時間要控制在53分鐘以內(nèi)，這對 DBA 來說是個挑戰(zhàn)，我們需要通過 MySQL 的高可用架構(gòu)設(shè)計來達到，當(dāng)然也需要針對數(shù)據(jù)庫進行備份。

　　Qunar 的 MySQL 高可用架構(gòu)有 MMM，PXC 和 QMHA，其中 PXC 和 QMHA 是自主開發(fā)設(shè)計的架構(gòu)，對外提供 namespace 服務(wù)，在強一致性、性能和跨機房服務(wù)間做權(quán)衡。

　　常用的數(shù)據(jù)庫有熱備份和冷備份，熱備份又分為物理熱備份和邏輯熱備份，各種備份方式都有優(yōu)缺點，企業(yè)需要根據(jù)自身的服務(wù)特點和需要進行選擇。互聯(lián)網(wǎng)企業(yè)一般都選擇熱備份，Qunar 也是。

　　備份恢復(fù)方式

　　優(yōu)點

　　缺點

　　熱備份(online backup)

　　物理熱備(InnoDB ibbackup、Percona XtraBackup)

　　速度快

　　MySQL版本綁定

　　邏輯熱備(mysqldump、mysqlpump)

　　簡單、備份樣式可選

　　sql語句,備份恢復(fù)速度慢

　　冷備份(offline backup)

　　操作簡單、拷貝數(shù)據(jù)文件

　　a.DB服務(wù)中斷業(yè)務(wù)受損

　　b.無法解決數(shù)據(jù)空洞問題

　　c.冷備恢復(fù)存在系統(tǒng)版本文件大小寫敏感和浮點數(shù)格式等問題

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

　　各個互聯(lián)網(wǎng)公司在備份方式都有這樣那樣的問題。

　　1本地存儲備份

　　這種備份方式占用本地磁盤空間和 IO，磁盤消耗大，比如數(shù)據(jù)庫500GB，那備份也要占用500GB，這樣磁盤容量就要翻倍，這是一種浪費。恢復(fù)時也要將備份集傳輸?shù)綄?yīng)機器上，這樣會占用線上數(shù)據(jù)庫服務(wù)器的網(wǎng)絡(luò)帶寬，會影響數(shù)據(jù)庫的正常業(yè)務(wù)訪問。

　　2備份方式選擇

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

　　3非集中管理

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

　　4備份文件校驗

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

　　5備份節(jié)點選擇

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

　　流量控制不好，會導(dǎo)致同一個機器上多個數(shù)據(jù)庫同時備份。我們現(xiàn)在都是單機多實例，如果這些實例同時備份就會對數(shù)據(jù)庫業(yè)務(wù)產(chǎn)生影響，所以這也是需要解決的問題之一。

　　7備份時間過長

　　由于數(shù)據(jù)庫太大，導(dǎo)致備份和恢復(fù)時間變長，故障的時間也響應(yīng)的變長。當(dāng)然備份過程中備份程序被阻塞也會使備份時間變長，比如備份時有一個長查詢阻塞了 FTWRL 的執(zhí)行，這樣我們需要解決阻塞的問題。備份時數(shù)據(jù)文件寫入的磁盤和網(wǎng)絡(luò)太慢也會導(dǎo)致備份時間延長。

　　好了，說了這么多備份恢復(fù)容易出現(xiàn)的問題，Qunar 是怎么做的呢？

　　Qunar 備份在每個機房都有一個 backup 角色的機器，用于存儲本機房內(nèi) MySQL 數(shù)據(jù)庫的備份，然后再傳輸?shù)竭h端的備份池 MFS。如圖：

　　針對單個機房的備份就是，備份節(jié)點執(zhí)行備份，流方式傳輸?shù)奖緳C房的 backup 上，然后再根據(jù)備份策略將過期的備份集傳輸?shù)?MFS 備份池，這樣就解決了本地存儲備份集的磁盤容量問題。如圖：

　　Qunar 的備份任務(wù)會采用專用的備份網(wǎng)卡，這樣不影響業(yè)務(wù)訪問數(shù)據(jù)庫，且同一個備份節(jié)點上的實例不會同時進行備份，備份任務(wù)都是獨立的。如圖：

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

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

　　下面是 Qunar 備份整體的任務(wù)流程圖。

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

　　1、封裝 Percona Xtranbackup 全量備份。

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

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

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

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

　　6、獨立的備份網(wǎng)卡，不占業(yè)務(wù)帶寬。

　　7、備份完成即一致性恢復(fù)，保證備份集邏輯上可用，備份集處于一致性狀態(tài)。

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

　　9、集中式后臺管理、調(diào)度，并發(fā)可控，狀態(tài)監(jiān)測，拋棄了 agent 和 crontab。

　　各個實例備份任務(wù)執(zhí)行情況。如圖：

　　添加備份任務(wù)。如圖：

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

　　自動化恢復(fù)，根據(jù)需要填寫要恢復(fù)的集群和目標(biāo)機。如圖：

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

　　公告通知

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

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

　　掃碼瀏覽 YMFE CONF 官網(wǎng)

　　掃碼購買 YMFE CONF 門票