db如何快速回滾和恢復，DBA的神技能！

　　【本文作者：58沈劍，本文來源架構師之路微信公眾號，轉載和授權請聯絡原作者】
　　
　　技術人如果經常線上操作DB，河邊走久了，難免出現紕漏：

　　update錯資料了

　　delete錯資料了

　　drop錯資料了

　　咋辦?找DBA恢復資料唄，即使恢復不了，鍋總得有人背呀。

　　畫外音：把資料全刪了，怎麼辦，怎麼辦?

　　零，哪種方案不能實現資料恢復?

　　從“從庫”恢復資料。

　　一般來說資料庫叢集是主從架構：

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

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

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

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

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

　　全量備份：定期(例如一個月)將庫檔案全量備份。

　　增量備份：定期(例如每天)將binlog增量備份。

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

　　(1)將最近一次全量備份的全庫找到，複製回來(檔案一般比較大)，解壓，應用;

　　(2)將最近一次全量備份後，每一天的增量binlog找到，複製回來(檔案較多)，依次重放;

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

　　恢復完畢。

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

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

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

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

　　畫外音：把幾T的資料傳輸過來都用了好長時間。

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

　　什麼是1小時延時從庫?

　　如上圖所示，增加一個從庫，這個從庫不是實時與主庫保持同步的，而是每隔1個小時同步一次主庫，同步完之後立馬斷開1小時，這個從庫會與主庫保持1個小時的資料差距。

　　當“刪全庫”事故發生時，如何利用“1小時延時從庫”快速恢復資料?

　　(1)應用1小時延時從;

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

　　快速恢復完畢。

　　這個方案的優點是，能夠快速找回資料。潛在不足是，萬一“1小時延時從庫”正在連上主庫進行同步的一小段時間內，發生了“刪庫”事故，也無法恢復。

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

　　什麼是雙份1小時延時從?

　　如上圖所示，兩個1小時延時從庫，它們連主庫同步資料的時間“岔開半小時”。

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

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

　　如何提高從庫利用效率?

　　對於一些“允許延時”的業務，可以使用1小時延時從，例如：

　　(1)運營後臺，產品後臺;

　　(2)BI進行資料同步;

　　(3)研發進行資料抽樣，調研;

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

　　五，總結

　　保證資料的安全性是DBA第一要務：

　　(0)理論上可以恢復+跑路;

　　(1)全量備份+增量備份+定期演練;

　　(2)1小時延時從庫;

　　(3)雙份1小時延時從庫+提高資源利用率;

　　DBA的神技能，學到了嗎，求轉。

　　貴司用的是哪種方案?