最近經常遇到開發(fā)同學在線上誤操作數(shù)據(jù)，有的是誤操作了一張表下的某些數(shù)據(jù)，還有的是表被刪掉了，甚至也有整個庫被誤刪。開發(fā)同學遇到這種情況通常是匆匆忙忙的找到DBA，問問有沒有補救的辦法，這時候DBA則會去看看這數(shù)據(jù)庫有沒有備份，備份可不可用，雖說這正是體驗DBA價值的時候，但是處理一個SQL的誤操作可能需要幾個小時甚至一天的時間，其實整個過程并不好受。如何避免這樣的情況，有沒有更加效率的處理辦法？

縮小用戶權限

個人賬號直接操作線上數(shù)據(jù)庫是不合理的，并且用戶在使用的過程中，測試和線上窗口來回切換，非常容易會把線上數(shù)據(jù)當成測試庫直接改掉，并且自己全然不知。針對這種情況應聯(lián)系開發(fā)同學確認其到底需要什么權限，用不到的權限建議回收掉。另外用戶在用個人賬戶連線上數(shù)據(jù)庫的時候SQL執(zhí)行完就應立即退出Session，不要開了很多窗口掛在那里，非常容易誤操作，良好的使用習慣也能夠大大降低誤操作的發(fā)生。

數(shù)據(jù)備份是最重要的一棵救命稻草

案例一：之前遇到過一次：某線上系統(tǒng)整個DataBase都被誤刪，導致整個服務不可用，當時這個數(shù)據(jù)庫處于無人托管的狀態(tài)，也沒有備份程序，所以整個恢復過程非常吃力,之后了解到有個QA同學前幾天剛好前幾天有過對這個庫做過一次全量的DUMP用來做測試，后來的恢復也全靠這份DUMP的數(shù)據(jù)，現(xiàn)在想起來也心有余悸，所以對DBA來說一定要確保所有的線上環(huán)境都有完整并且可用的數(shù)據(jù)庫備份。

??????? ????

??

DBA高效響應用戶需求才能體現(xiàn)價值

我們經常會遇到的情況是：當用戶誤刪數(shù)據(jù)時，我們備份都有，但是做的時候才發(fā)現(xiàn)把這些備份都恢復出來其實是個挺費時間的工作。

案例二：線上某核心產品用戶數(shù)據(jù)被開發(fā)誤更新，導致用戶個人信息有有一列數(shù)據(jù)錯誤，開發(fā)同學火急火燎的要馬上恢復導誤更新之前的狀態(tài)，但是實際情況是這個產品使用的是分布式數(shù)據(jù)庫，底層所使用的是多個MySQL實例，DBA需要手動的把這幾個MySQL的備份一個一個找出來然后再從網上或者別的服務器上拷貝一個恢復程序，然后自己再人肉拼恢復命令，整個過程還涉及到把這個備份從備份服務器上遠程COPY出來，恢復完成后再通過做Slave回放Binlog，所以整個過程都有可能超過幾個小時甚至半天，如果能把整個過程自動化掉，通過程序一鍵幫助我們恢復導一個我們指定的時間點，其實可以節(jié)省很多時間，并且也減輕DBA的負擔，對用戶的影響也會更少一點。

數(shù)據(jù)庫合理配置

很多數(shù)據(jù)誤刪的情況大多是一個Update或者一個DELETE，可能影響到的只是幾十行或者幾百行的數(shù)據(jù)，這樣我們再去拉備份做同步無非是顯得有點小題大作，有沒有更效率的方法解決問題呢？

大家都知道Oracle數(shù)據(jù)庫有個閃回功能，能夠自動的把最近一段時間內的數(shù)據(jù)恢復，那么MySQL有這樣的東西嗎？官方MySQL版本其實是沒有這樣的工具的，但是作為開源數(shù)據(jù)庫的領頭羊，MySQL吸納了太多有意思的功能，MySQL的?FlashBack就是其中的一個。

這個Patch的實現(xiàn)思路還算比較簡單，舉例說：比如用戶在時間點T1把表T從1改成了2，然后在時間點T2把表T從2改成3，那么如何把表T恢復到T1的時間點呢？這個工具通過解析BINLOG的方式完成回滾，因為用戶其實在T1和T2兩個時間點做了兩個UPDATE，所以工具要做的只是根據(jù)BINLOG里面的內存把這兩個UPDATE逆向解析并執(zhí)行就OK了，所以會幫我們自動的轉化為Update T 3--->2 , UpdateT 2--->1 ， 這樣就完成了數(shù)據(jù)的回滾，但是這個工具依賴于MySQLBinlog的格式必須要求binlog_format是ROW才能解析，因為在解析的構成中需要從BinlOG里面獲得很多元數(shù)據(jù)信息。

該Patch最早來源于淘寶，后來我們公司內部MySQL分支版本：InnoSQL 已經把這個功能吸納進到了我們的版本中，并且我們在他的基礎上進行了加強，因為他只能完成DML的回滾，DDL的回滾是無能為力的，我們在它的基礎上完善了DDL的回滾，當然也非常感謝淘寶貢獻了這么好的PATCH與想法。這樣的話通過這個工具即使沒有數(shù)據(jù)庫備份，只有有BINLOG并且日志級別是ROW的話也能非常快的完成數(shù)據(jù)的回滾操作，簡化了操作流程。

延遲鏡像可能是恢復數(shù)據(jù)的最后一根救命稻草

案例三：之前線上有個非常大的數(shù)據(jù)庫，數(shù)據(jù)量:>1T ，寫入量非常大，屬于后臺系統(tǒng)但是數(shù)據(jù)非常重要，每天很多人都要用到這個系統(tǒng)。因為這個庫非常大導致數(shù)據(jù)庫的備份功能很難進行，因為沒有充足的存儲資源做備份，剛巧開發(fā)同學一個誤操作把這個系統(tǒng)的用戶表更新掉了，把所有人的mobile更新成一個手機號，因為這是運維監(jiān)控系統(tǒng)，所以誤操作完之后這個手機號就開始瘋狂的收報警信息...當時可以確認的是這個庫沒有備份，并且BINLOG的格式不是ROW，在幾乎毫無辦法的情況下驚喜的發(fā)現(xiàn)這個庫竟然有個從庫延遲了半天左右，當時真的是驚喜若狂，馬上停掉鏡像進行恢復，在MySQL5.6版本之前可以使用Percona的第三方工具完成延遲從庫的功能，在MySQL5.6版本之后官方版本就提供了延遲從庫的功能。

數(shù)據(jù)誤更新對產品和DBA來說都是一件不愿意看到的事情，所以在分配線上數(shù)據(jù)庫權限的時候一定要細化，個人賬戶盡可能的只申請最小權限。開發(fā)同學在使用數(shù)據(jù)庫查詢的時候也要養(yǎng)成良好的使用習慣，不要多個窗口同時開著，也不要線上和測試同時開著。另外DBA在遇到這種情況的時候還是需要冷靜處理，要定時對備份做巡檢確保備份都是可用且可靠的，MySQL線上Binlog格式盡量全部改成ROW格式，核心業(yè)務配上一個延遲從庫，關鍵時候可能會救命。

最后愿天下再也沒有誤操作。

網易云信∣真正穩(wěn)定的IM云服務

ID：neteaseim ?長按識別，關注精彩

總結

以上是生活随笔為你收集整理的【干货分享】如何应对线上数据库的误操作的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。