[[380664]]

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

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

最近經過一段時間的沉淀，發現成功率竟然從93%下降到了88%，

為了保證恢復任務的可執行性，目前是采用了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 & 

為了提高恢復的吞吐量和效率，目前是使用了3臺恢復機器來實現基于IDC的動態調度。

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

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

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

對于任務的調度時間，我進一步分析，發現還是由潛在的風險的，目前的測試基數還是比較小，按照每3小時執行1次，2個定時任務觸發的模式，一天差不多會有12個左右的任務。

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

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

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

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

本文轉載自微信公眾號「楊建榮的學習筆記」，可以通過以下二維碼關注。轉載本文請聯系楊建榮的學習筆記公眾號。