誤刪數(shù)據(jù)庫怎么辦

這篇文章主要講解了“誤刪數(shù)據(jù)庫怎么辦”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“誤刪數(shù)據(jù)庫怎么辦”吧！

一般情況如果在大公司刪庫刪表這種情況基本上不會遇到，畢竟給咱們開發(fā)的賬號不會開這么高的權(quán)限。但是在小公司的話就不一定，沒這么規(guī)范，要是咱們手抖一下，不小心刪錯了咋辦？

比如你delete錯了,把別的行給刪了。然后如果你的數(shù)據(jù)庫binlog配置是

binlog_format = row 和 binlog_row_image = FULL

比如你的delete語句對應(yīng)的binlog event 類型是

Delete_rows event

然后將它改成

Write_rows event;

把修改的binlog拿回原庫重放就行了。

如果是你update的話，那binlog里面也是記錄了數(shù)據(jù)修改前和修改后的值的，你只要對調(diào)這兩行數(shù)據(jù)的位置就行。

推薦使用Flashback工具，工具的原理就是我上面說的那樣。

還有這種操作不建議在主庫上執(zhí)行，一般情況是備份一個庫，或者在哪個從庫上執(zhí)行這些操作，確認(rèn)沒問題的然后再回復(fù)主庫確保主庫的安全。

但是有些哥們可能比較猛，他可能是drop或者truncate哪個table了或者是drop database了。這種情況下binlog記得只會是一個drop/truncate語句，所以用上面的方法是搞不定的。

咋辦呢，找之前的全量備份，沒得話...你懂得

找到之前的全量備份然后配合增量的日志恢復(fù)。流程就是：

1. 找到最近一次的全量備份。比如是2019-3-25 晚上11點

2. 通過這個備份恢復(fù)出一個臨時庫

3. 在日志備份里面找到2019-3-25 晚上11點之后的日志

4. 將這些日志除了誤刪除的那個語句全部應(yīng)用到臨時庫上
   

第4條這個操作，如果你的數(shù)據(jù)庫實例用了GTID模式，就先

set gtid_next=(你的刪除語句的GTID);begin;commit;

如果沒用這個模式，那只能是應(yīng)用到這個刪除語句之前先用-stop-position參數(shù)執(zhí)行到這個語句之前，然后-start-position開始這個語句之后的執(zhí)行。

我們做主從備份，為了防止誤刪數(shù)據(jù)導(dǎo)致的問題，可以搞一個延遲一小時的從庫，就比如我們是一個星期備份一次的，那我們?nèi)绻诘谄咛斐隽耸裁村e，需要恢復(fù)的話，那得跑多久??！所以弄一個特殊的備庫，通過

CHANGE MASTER TO MASTER_DELAY = N

來設(shè)置這個備庫和主庫有N秒的延遲，這樣發(fā)現(xiàn)主庫誤操作了，馬上再這個備庫上執(zhí)行 stop slave，然后通過上面的方法跳過誤刪除的命令，恢復(fù)數(shù)據(jù)！

感謝各位的閱讀，以上就是“誤刪數(shù)據(jù)庫怎么辦”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對誤刪數(shù)據(jù)庫怎么辦這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！