MySQL中如何實現(xiàn)隨機(jī)恢復(fù)

這篇文章給大家介紹MySQL中如何實現(xiàn)隨機(jī)恢復(fù)，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

1)數(shù)據(jù)庫參數(shù)配置不規(guī)范，/etc/my.cnf和/data/mysql_xxx/my.cnf的配置不匹配，導(dǎo)致實例啟動失敗

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

3)binlog解析出錯，導(dǎo)致后續(xù)恢復(fù)失敗

4)備份集恢復(fù)出錯，導(dǎo)致整體恢復(fù)失敗

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

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

目前的恢復(fù)主要有基于備份集恢復(fù)，基于時間點恢復(fù)，對象粒度的恢復(fù)和表結(jié)構(gòu)恢復(fù)，我們通常所說的系統(tǒng)層恢復(fù)主要是基于備份集恢復(fù)和基于時間點恢復(fù)。

為此我設(shè)計和實現(xiàn)了如下的基本流程：

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

所以多次隨機(jī)，能夠讓這個事情的判斷會更加明確，恢復(fù)質(zhì)量一目了然。

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

1)隨機(jī)需要保證在一定的時間范圍內(nèi)，所有實例都能夠覆蓋到

2)對恢復(fù)機(jī)進(jìn)行線性擴(kuò)展，比如提供一個恢復(fù)服務(wù)器組，可以在上面并行的跑一些恢復(fù)任務(wù)，提高恢復(fù)響應(yīng)效率

3)對恢復(fù)結(jié)果進(jìn)行日報可視化，恢復(fù)了哪些，效率如何，對一定時間周期內(nèi)的恢復(fù)結(jié)果進(jìn)行匯總和復(fù)盤

4)根據(jù)推斷統(tǒng)計的思維，采取一定樣本的數(shù)據(jù)，通過假設(shè)檢驗，建立相應(yīng)的數(shù)據(jù)模型來進(jìn)行檢驗和分析

關(guān)于MySQL中如何實現(xiàn)隨機(jī)恢復(fù)就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。