[[380664]]

最近在進一步優(yōu)化隨機恢復(fù)的成功率問題，本來預(yù)計是2周內(nèi)能夠快速結(jié)束，從1個9的恢復(fù)能力快速提升到2個9，結(jié)果這個Flag立下了，但是最終的結(jié)果和付出的努力遠比想象中要高。

其實有很多同學(xué)不大理解為什么2個9那么難，整體來說，數(shù)據(jù)備份是基于一次全量永遠增量的模式，數(shù)據(jù)量會不斷增長，所以數(shù)據(jù)是動態(tài)變化的，另外如何恢復(fù)數(shù)據(jù)的需求是動態(tài)的，比如我可以隨機指定1個時間，比如這一次是2:00，下一次可能是3:20，不確定的時間就會給已有的服務(wù)帶來新的潛在不確定性，此外絕大多數(shù)的問題是在數(shù)據(jù)庫啟動期間發(fā)生，通常會和存儲容量，插件配置，參數(shù)配置相關(guān)，如果報錯，盡管手工修復(fù)也可以搞定，只要啟動報錯，我們也會按照失敗來計算，所以驗收標準算是比較簡單清晰的。

最近經(jīng)過一段時間的沉淀，發(fā)現(xiàn)成功率竟然從93%下降到了88%，

為了保證恢復(fù)任務(wù)的可執(zhí)行性，目前是采用了crontab的模式，如下：

30 7-23/3 * * * /usr/bin/python /root/crontab_tasks/random_recover.py  >> /root/crontab_tasks/log/random_recover.log & 
00 6-22/3 * * * /usr/bin/python /root/crontab_tasks/random_recover.py  >> /root/crontab_tasks/log/random_recover.log & 

為了提高恢復(fù)的吞吐量和效率，目前是使用了3臺恢復(fù)機器來實現(xiàn)基于IDC的動態(tài)調(diào)度。

基于之前的失敗數(shù)據(jù)，我的第一輪測試選取了23個樣本，恢復(fù)的過程相對比較快，指定恢復(fù)到dn1這臺恢復(fù)機器后，恢復(fù)成功率達到了100%，有點讓我驚呆。

然后我重新選擇了dn2,再次恢復(fù)了同樣的23個樣本實例，這一次，竟然失敗了3個，而專門再次恢復(fù)，就沒有問題了，著實讓我有些意外

通過這樣的測試，我做了進一步的分析，發(fā)現(xiàn)問題主要出現(xiàn)在binlog的回放方面，所以可以初步斷定，在binlog的有效性方面還是存在潛在的問題，目前的隨機時間范圍是在3-24小時之內(nèi)，所以我先刻意調(diào)整了時間范圍，把它先縮短。

對于任務(wù)的調(diào)度時間，我進一步分析，發(fā)現(xiàn)還是由潛在的風(fēng)險的，目前的測試基數(shù)還是比較小，按照每3小時執(zhí)行1次，2個定時任務(wù)觸發(fā)的模式，一天差不多會有12個左右的任務(wù)。

這種調(diào)度模式的缺點就是對于任務(wù)的執(zhí)行沒有彈性，如果數(shù)據(jù)恢復(fù)時間超過1個小時，基本上就是失敗了。另外就是dn1,dn2,dn3的任務(wù)選擇也是隨機的，帶來的隱患就是如果dn1被選定恢復(fù)，很可能下次還是會隨機為dn1繼續(xù)恢復(fù)，就會導(dǎo)致dn2,dn3都始終處于閑置狀態(tài)。

一種較為理想的方式是，可以定制恢復(fù)的基數(shù)，比如目前是12次，基本是每隔小時都會觸發(fā)一次，如果我們需要恢復(fù)20次，那么平攤到每臺恢復(fù)機器的調(diào)用次數(shù)差不多是7次，相對來說還是比較寬松的，如果按照強調(diào)度模式，那么可以支撐的基數(shù)最大是48次左右。

如果跟進一步，我們做成即時響應(yīng)模式，即dn1恢復(fù)之后馬上觸發(fā)下一波的恢復(fù)任務(wù)，那么這個基數(shù)的提升會直接乘以3，還是比較強悍的。

所以馬上要做的改進就是把這3臺恢復(fù)機器用活，讓他們不要始終處于閑置狀態(tài)。否則就是下面的狀態(tài)。

本文轉(zhuǎn)載自微信公眾號「楊建榮的學(xué)習(xí)筆記」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系楊建榮的學(xué)習(xí)筆記公眾號。