MySQL隨機恢複的設計思路

楊建榮的數據庫筆記

作家

比如下面的場景：

1）數據庫參數配置不規範，/etc/my.cnf和/data/mysql_xxx/my.cnf的配置不匹配，導致實例啟動失敗

2）數據庫版本差異化，比如主流支持是5.7，突然冒出來一個5.6的版本

3）binlog解析出錯，導致後續恢複失敗

4）備份集恢複出錯，導致整體恢複失敗

如此種種的案例數不勝數，稍有不慎，就難以恢複，而像配置類的問題，雖然可以解決，但是在緊急情況下，恢複流程失敗，很難保證有良好的心態能夠快速解決，所以對於恢複質量的檢驗是過去我們一直在犯的錯誤：我們一直在完善備份，但是對於恢複側卻少有關注，認為應該是可以的
，恰恰是這個應該會把我們拖入被動局面。

所以我冒出來一個隨機恢複
的想法，還是假設有500個實例，那麼這些實例如果我們一一恢複，每天的工作量是很龐大的，而且對系統的負載也很高，所以如果我們把風險和成本做一個綜合，這個工作的效率和意義就會很明顯。

目前的恢複主要有基於備份集恢複，基於時間點恢複，對象粒度的恢複和表結構恢複，我們通常所說的系統層恢複主要是基於備份集恢複和基於時間點恢複。

為此我設計和實現了如下的基本流程：

需要補充的是，隨機時間是在備份集的時間周期內，而隨機時間戳，則是按照近24小時內的一個隨機時間點。

所以多次隨機，能夠讓這個事情的判斷會更加明確，恢複質量一目了然。

在這個基礎上還需要一系列的事情：

1）隨機需要保證在一定的時間範圍內，所有實例都能夠覆蓋到

2）對恢複機進行線性擴展，比如提供一個恢複服務器組，可以在上面並行的跑一些恢複任務，提高恢複響應效率

3）對恢複結果進行日報可視化，恢複了哪些，效率如何，對一定時間周期內的恢複結果進行匯總和複盤

4）根據推斷統計的思維，采取一定樣本的數據，通過假設檢驗，建立相應的數據模型來進行檢驗和分析