即使刪了全庫，保證半小時恢復
近期一篇《就這樣把根目錄刪了！！！》引發了廣泛的討論，《如何防止根目錄被刪》彙總了7種防刪方案。還有同學評論中反饋“不小心把庫刪了”，如何快速恢復刪掉的數據庫，是今天要討論的話題。
【高可用數據庫架構】
一般來說數據庫集羣會是主從架構：
或者主主架構：
如果此時主庫宕機，可以：
（1）一個從庫頂上，重建集羣
（2）流量遷移到另一個主庫
來保證數據的安全性與服務的可用性。
但是，如果人爲不小心執行了“刪全庫”操作，命令會同步給其他從（主）庫，導致所有庫上的數據全部丟失，這下怎麼辦呢？
可以問問自己，當這種情況發生的時候：
（1）能不能恢復數據？（應該沒有公司不能）
（2）多久能夠恢復數據？
保證數據的安全性是DBA第一要務。
【全量備份+增量備份】
常見的數據庫安全性策略是：全量備份+增量備份。
全量備份：定期（例如一個月）將庫文件全量備份
增量備份：定期（例如每天）將binlog增量備份
如果不小心誤刪了全庫，可以這麼恢復：
（1）將最近一次全量備份的全庫找到，拷貝回來（文件一般比較大），解壓，應用
（2）將最近一次全量備份後，每一天的增量binlog找到，拷貝回來（文件較多），依次重放
（3）將最近一次增量備份後，到執行“刪全庫”之前的binlog找到，重放
恢復完畢。
爲了保證方案的可靠性，建議定期進行恢復演練。
方案優點：能夠找回數據
方案缺點：恢復時間非常長
有沒有更優，更快恢復的方案呢？
【1小時延時從】
使用1小時延時從庫，可大大加速“刪全庫”恢復時間。
什麼是1小時延時從？
如圖所示，增加一個從庫，這個從庫不是實時與主庫保持同步的，而是每隔1個小時同步一次主庫，同步完之後立馬斷開1小時，這個從庫會與主庫保持1個小時的數據差距。
當“刪全庫”事故發生時，只需要：
（1）應用1小時延時從
（2）將1小時延時從最近一次同步時間到，將執行“刪全庫”之前的binlog找到，重放
快速恢復完畢。
方案優點：能夠快速找回數據
潛在不足：萬一，萬一，萬一，1小時延時從正在連上主庫進行同步的一小段時間內，發生了“刪全庫”事故，那怎麼辦咧？
【雙份1小時延時從】
使用雙份1小時延時從庫，可以避免上述“萬一，萬一，萬一”的事故發生。
什麼是雙份1小時延時從？
如圖所示，兩個1小時延時從，他們連主庫同步數據的時間“岔開半小時”。
這樣，即使一個延時從連上主庫進行同步的一小段時間內，發生了“刪全庫”事故，依然有另一個延時從保有半小時之前的數據，可以實施快速恢復。
方案優點：沒有萬一，都能快速恢復數據
潛在不足：資源利用率有點低，爲了保證數據的安全性，多了2臺延時從，降低了從庫利用率
【提高從庫效率】
1小時延時從也不是完全沒有用，對於一些“允許延時”的業務，可以使用1小時延時從，例如：
（1）運營後臺，產品後臺
（2）BI進行數據同步
（3）研發進行數據抽樣，調研
但需要注意的是，畢竟這是從庫，只能夠提供“只讀”服務喲。
【總結】
保證數據的安全性是DBA第一要務，需要進行：
（1）全量備份+增量備份，並定期進行恢復演練，但該方案恢復時間較久，對系統可用性影響大
（2）1小時延時從，雙份1小時延時從能極大加速數據庫恢復時間
（3）個人建議1小時延時從足夠，後臺只讀服務可以連1小時延時從，提高資源利用率
轉自：58沈劍 架構師之路