即使刪了全庫，保證半小時恢復(fù)

【高可用數(shù)據(jù)庫架構(gòu)】

---

一般來說數(shù)據(jù)庫集群會是主從架構(gòu)：

如果此時主庫宕機，可以：

（1）一個從庫頂上，重建集群

（2）流量遷移到另一個主庫

來保證數(shù)據(jù)的安全性與服務(wù)的可用性。

但是，如果人為不小心執(zhí)行了“刪全庫”操作，命令會同步給其他從（主）庫，導(dǎo)致所有庫上的數(shù)據(jù)全部丟失，這下怎么辦呢？

可以問問自己，當這種情況發(fā)生的時候：

（1）能不能恢復(fù)數(shù)據(jù)？（應(yīng)該沒有公司不能）

（2）多久能夠恢復(fù)數(shù)據(jù)？

保證數(shù)據(jù)的安全性是DBA第一要務(wù)。

【全量備份+增量備份】

---

常見的數(shù)據(jù)庫安全性策略是：全量備份+增量備份。

如果不小心誤刪了全庫，可以這么恢復(fù)：

（1）將最近一次全量備份的全庫找到，拷貝回來（文件一般比較大），解壓，應(yīng)用

（2）將最近一次全量備份后，每一天的增量binlog找到，拷貝回來（文件較多），依次重放

（3）將最近一次增量備份后，到執(zhí)行“刪全庫”之前的binlog找到，重放

恢復(fù)完畢。

為了保證方案的可靠性，建議定期進行恢復(fù)演練。

方案優(yōu)點：能夠找回數(shù)據(jù)

方案缺點：恢復(fù)時間非常長

有沒有更優(yōu)，更快恢復(fù)的方案呢？

【1小時延時從】

---

使用1小時延時從庫，可大大加速“刪全庫”恢復(fù)時間。

什么是1小時延時從？

如圖所示，增加一個從庫，這個從庫不是實時與主庫保持同步的，而是每隔1個小時同步一次主庫，同步完之后立馬斷開1小時，這個從庫會與主庫保持1個小時的數(shù)據(jù)差距。

當“刪全庫”事故發(fā)生時，只需要：

（1）應(yīng)用1小時延時從

（2）將1小時延時從最近一次同步時間到，將執(zhí)行“刪全庫”之前的binlog找到，重放

快速恢復(fù)完畢。

方案優(yōu)點：能夠快速找回數(shù)據(jù)

潛在不足：萬一，萬一，萬一，1小時延時從正在連上主庫進行同步的一小段時間內(nèi)，發(fā)生了“刪全庫”事故，那怎么辦咧？

【雙份1小時延時從】

---

使用雙份1小時延時從庫，可以避免上述“萬一，萬一，萬一”的事故發(fā)生。

什么是雙份1小時延時從？

如圖所示，兩個1小時延時從，他們連主庫同步數(shù)據(jù)的時間“岔開半小時”。

這樣，即使一個延時從連上主庫進行同步的一小段時間內(nèi)，發(fā)生了“刪全庫”事故，依然有另一個延時從保有半小時之前的數(shù)據(jù)，可以實施快速恢復(fù)。

方案優(yōu)點：沒有萬一，都能快速恢復(fù)數(shù)據(jù)

潛在不足：資源利用率有點低，為了保證數(shù)據(jù)的安全性，多了2臺延時從，降低了從庫利用率

【提高從庫效率】

---

1小時延時從也不是完全沒有用，對于一些“允許延時”的業(yè)務(wù)，可以使用1小時延時從，例如：

（1）運營后臺，產(chǎn)品后臺

（2）BI進行數(shù)據(jù)同步

（3）研發(fā)進行數(shù)據(jù)抽樣，調(diào)研

但需要注意的是，畢竟這是從庫，只能夠提供“只讀”服務(wù)喲。

【總結(jié)】

---

保證數(shù)據(jù)的安全性是DBA第一要務(wù)，需要進行：

（1）全量備份+增量備份，并定期進行恢復(fù)演練，但該方案恢復(fù)時間較久，對系統(tǒng)可用性影響大

（2）1小時延時從，雙份1小時延時從能極大加速數(shù)據(jù)庫恢復(fù)時間

（3）個人建議1小時延時從足夠，后臺只讀服務(wù)可以連1小時延時從，提高資源利用率