高可用數據庫架構
一般來說數據庫集群會是主從架構：
或者主主架構：
如果此時主庫宕機，可以：
- 一個從庫頂上，重建集群
- 流量遷移到另一個主庫
來保證數據的安全性與服務的可用性。
但是，如果人為不小心執行了“刪全庫”操作，命令會同步給其他從（主）庫，導致所有庫上的數據全部丟失，這下怎么辦呢？
可以問問自己，當這種情況發生的時候：
- 能不能恢復數據？（應該沒有公司不能）
- 多久能夠恢復數據？
保證數據的安全性是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小時延時從，提高資源利用率