如果沒有恢復(fù)場景，備份就失去了業(yè)務(wù)價值，畢竟單純靠業(yè)務(wù)價值一把尺子就衡量系統(tǒng)建設(shè)其實是不公平的，但是如果數(shù)據(jù)沒有恢復(fù)成功，備份就失去了任何價值。

數(shù)據(jù)庫這個圈子，其實比較垂直，能叫出名字的就是那么些人，所以數(shù)據(jù)恢復(fù)是一個很差的標(biāo)簽，而且刪庫跑路也是行不通的。

我們可以以退為進(jìn)，把一些工作轉(zhuǎn)變?yōu)橹鲃印＜僭O(shè)我有1000臺數(shù)據(jù)庫實例，其中從庫和單實例節(jié)點有500個，那么如何保障這500個數(shù)據(jù)庫實例的數(shù)據(jù)可以恢復(fù)，在可以恢復(fù)的前提下，如何提高恢復(fù)效率，然后整體上來看，如何綜合提升備份效率，備份任務(wù)調(diào)度，如何通過增量來落實“一次全量，永遠(yuǎn)增量”的設(shè)計模式，這些措施都會有改進(jìn)，但是對于數(shù)據(jù)恢復(fù)效率還是很難保證的。

比如下面的場景：

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)該會把我們拖入被動局面。

所以我冒出來一個隨機恢復(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)了如下的基本流程：

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

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

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

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

2)對恢復(fù)機進(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)行檢驗和分析

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