技術人如果經常線上操作DB，河邊走久了，難免出現(xiàn)紕漏：

• update錯數(shù)據(jù)了
• delete錯數(shù)據(jù)了
• drop錯數(shù)據(jù)了

咋辦？找DBA恢復數(shù)據(jù)唄，即使恢復不了，鍋總得有人背呀。

畫外音：把數(shù)據(jù)全刪了，怎么辦，怎么辦？

零，哪種方案不能實現(xiàn)數(shù)據(jù)恢復？

從“從庫”恢復數(shù)據(jù)。

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

如果人為執(zhí)行了“刪庫”操作，命令會同步給其他從庫，導致所有庫上的數(shù)據(jù)全被刪除，無法恢復，故這種方案是不行的。

一，如果DBA沒有做功課，最常見的處理方案是什么？

如果沒有做數(shù)據(jù)安全方案，應對“刪庫”最常見的操作是，跑路。刪掉了公司最重要的資產，還不快閃。 

二，如果DBA日常做了全量備份+增量備份，應該怎么處理？

DBA最常見的技能是：全量備份+增量備份。

全量備份：定期（例如一個月）將庫文件全量備份。

增量備份：定期（例如每天）將binlog增量備份。 

如果不小心“刪庫”，可以這么恢復：

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

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

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

恢復完畢。

為了保證方案的可靠性，需要定期進行演練。

咦，我怎么好像沒聽過DBA定期做過這類演練？

很有可能只是做了理論上的方案，如果真出了問題，效果也只是理論上能恢復。此時回歸方案一，跑路。

全量備份+增量備份的恢復周期也非常長，可能是天級別。

畫外音：把幾T的數(shù)據(jù)傳輸過來都用了好長時間。 

三，如果DBA做了“1小時延時從庫”，應該怎么處理？

什么是1小時延時從庫？

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

當“刪全庫”事故發(fā)生時，如何利用“1小時延時從庫”快速恢復數(shù)據(jù)？

（1）應用1小時延時從；

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

快速恢復完畢。 

這個方案的優(yōu)點是，能夠快速找回數(shù)據(jù)。潛在不足是，萬一“1小時延時從庫”正在連上主庫進行同步的一小段時間內，發(fā)生了“刪庫”事故，也無法恢復。 

四，如果DBA做了“雙份1小時延時從庫”，應該怎么處理？

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

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

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

這個方案的優(yōu)點是，沒有萬一，一定能快速恢復數(shù)據(jù)。潛在的不足是，資源利用率有點低，為了保證數(shù)據(jù)的安全性，多了2臺延時從，降低了從庫利用率。 

如何提高從庫利用效率？

對于一些“允許延時”的業(yè)務，可以使用1小時延時從，例如：

（1）運營后臺，產品后臺；

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

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

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

五，總結

保證數(shù)據(jù)的安全性是DBA***要務：

（0）理論上可以恢復+跑路；

（1）全量備份+增量備份+定期演練；

（2）1小時延時從庫；

（3）雙份1小時延時從庫+提高資源利用率；