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

縮小用戶權(quán)限

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

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

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

??????? ????

??

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

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

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

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

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

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

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

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

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

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

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

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

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

ID：neteaseim ?長按識別，關(guān)注精彩

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。