Python自動化運維系列 | 不小心刪除了公司數(shù)據(jù)庫，是什么樣一種體驗？
人生大起大落落落落落落，實在是太刺激了，下面這真是一個悲傷的故事。
那年公司 ERP 系統(tǒng)剛進行升級。
因為公司陸續(xù)上了 MES 和 PDM 系統(tǒng)。為了加快整個公司信息化平臺的統(tǒng)一，請了個第三方公司來做中間接口。
然后故事開始了。
某一個晚上，第三方人員問我要 ERP 的 SA 密碼。
我很警惕：“你要干嘛？”
“我測試一下中間表。”
“有沒有寫表的操作？”
“沒有，只有讀表的操作。”
于是我放心的給了 SA 密碼。給了 VPN 權(quán)限通道。放她進來了。
十分鐘后…..
她帶著哭腔打電話來（是的，對方做測試的是個 93 年的萌妹子。）
“吳哥哥，服務器中毒了。。。。”
我當時還在逛果殼呢，一聽她說我服務器中毒了，我表示無比淡定。還以大哥的經(jīng)驗教訓了一頓她。
“叫你不要往我服務器傳插件嘛，這次幫你解決一下，下次不準了喲。”
我認為是小 case 呢，不就中毒了嘛，系統(tǒng)往回滾一天就好了。
然后悲劇的事情就出現(xiàn)了，遠程進不去，于是我就去機房本地登錄，居然也進不去。
我不死心，強制重啟，居然還是進不去。我的服務器系統(tǒng)就這樣崩了。。。
好在那幾天在做開發(fā)，系統(tǒng)沒有啟用，于是我和我的老板匯報了這個情況：
“老大，我們服務器系統(tǒng)崩了。”
“哦，那就搞好它讓它別崩。” ?果然是霸道總裁啊。
當時數(shù)據(jù)和應用服務器我都是分開跑的，所以應用服務器奔潰了，我覺得也沒多大事，就重新做系統(tǒng)吧。于是我重新做了個系統(tǒng)，然后喊萌妹子上來搭平臺。
“小劉啊，你可害慘我了，一個下午給你重做服務器系統(tǒng)了，我基礎(chǔ)環(huán)境都配置好了，你上來搭平臺吧。”
萌妹子那是無比的歉意啊，又是答應請我吃飯又是答應請我看電影的。我都想系統(tǒng)再崩潰一次了。
按理說這樣應該是沒問題了，就在我走出機房，在外面抽了根煙，45 度仰望了一下天空，聯(lián)想了一下和萌妹子點個 9 分熟的牛排，在喝一口二鍋頭這樣浪漫的晚餐的時候。電話來了。
來電話的是萌妹子的老板。
“小吳，我想找一下 information.db 和 mfmedia.db 這兩個總表沒找到，你給我找一下。”
我都蒙了，從來沒人問過我這樣的問題，難道她老板不是 IT 行業(yè)的。
“數(shù)據(jù)庫文件都在目錄樹里啊，自己去找啊。”
“沒有。”
于是我登上服務器一看，我傻了。所有的表都空了，所有的表都靜靜的躺在那，但是里面都空了。。。
不可能啊，我數(shù)據(jù)庫是放在另外一臺服務器上的，怎么可能會沒有了。
于是我問萌妹子：“XXX，你到底做了什么操作啊，為毛我數(shù)據(jù)庫都沒了。”
萌妹子說：“我啥也沒干啊，只是按照步驟一路點 YES。”
我才想起來，在第一次配置基礎(chǔ)環(huán)境的時候，建賬套會提示是否初始環(huán)境，如果點是了，數(shù)據(jù)庫就會被初始化，然后這位萌妹子傻傻的點了是。
“你知道不知道你干了什么，公司 06 年到現(xiàn)在所有的數(shù)據(jù)，財務的，供應鏈的，進銷存的全部都在這臺服務器里，200 多個 G 數(shù)據(jù)，因為你一個是，全沒了。”
萌妹子也嚇蒙了，話都說不出來了。
沒辦法，我再給我老板打電話。
“老板，有個好消息，有個壞消息。”
“直接說壞的。” 我就喜歡我們老板這么直接。
“恩。。恩。。那個。。就是那個。ERP 的數(shù)據(jù)沒了。”
“哦，那就找回來。” 老板還是那么的霸氣。我特么都要愛上他了。
“老板，我想你沒明白這個的嚴重性。ERP 數(shù)據(jù)沒了，從 06 年開始的都沒了，這意味著就算找回來，整理所有的表，排錯也需要 3 天左右時間，到時候所有的生產(chǎn)都要暫時停止。如果找不回來，我們可能就要倒閉了。”
我忽然有種掌握天下蒼生的感覺。。。
對面沉默了 5 秒后，爆吼了一句：“吳 XX，你給我滾到我辦公室來!!”
中間和老板手握手談心，被老板親切慰問的細節(jié)跳過不表。
當時公司高層對數(shù)據(jù)安全還沒有那么重視，之前預算做的項目，我已經(jīng)做了備份的計劃書，一直沒被審批下來，現(xiàn)在估計悔得腸子都清了。
于是我開始漫長的數(shù)據(jù)恢復之旅。
我之前已經(jīng)做了個本地備份的計劃，每天晚上會備份一次。我把希望都放在了它身上。等我把備份的數(shù)據(jù)庫附件上去，發(fā)現(xiàn)時間居然都是兩個星期之前的。
而且還有一些新表都沒有，我聯(lián)系對方，對方告知研發(fā)人員兩個星期前做測試的時候把備份計劃關(guān)了。。。
我心里萬頭草泥馬奔騰而過。
最后沒有辦法，把老服務器又翻了出來，翻出之前的老數(shù)據(jù)，開始轉(zhuǎn)換。
期間老板給我短信：“數(shù)據(jù)恢復進行的怎么樣了呢。”
“報告，正在穩(wěn)步進行中，按照目前的狀況，可恢復的可能性超過 90%。” 別問我 90% 怎么算出來的，我就是哄他才這樣說的。
“唉，真是心急呀，睡都睡不著。小吳呀，當初要是聽你的，上了備份該多好呀。” 現(xiàn)在知道后悔了，哼哼。
“老大別擔心，我會搞定的。” 是的，作為一位負責的員工，我就是這么讓老大心安。
“恩，那就交給你了哦，熬夜少抽點煙哦。” 哎呀，瞬間覺得我老大萌萌噠有沒有。
這里花了我一個晚上加一個白天。
數(shù)據(jù)轉(zhuǎn)換好了，還有一些時間差的數(shù)據(jù)沒法找到。于是通知各個部門，找單據(jù)，開始往里面補單子，一條一條的按照業(yè)務流程補進去。
為了協(xié)同更方便，在會議室加設了幾十臺電腦集體辦公。。。
在大家一片怨聲載道中，三天時間，終于把數(shù)據(jù)恢復了過來。三天內(nèi)我沒離開機房超過 10 米，吃喝拉撒都在機房，不對，拉撒不在。
1. 大部分員工放假三天，我加班三天三夜。
2. 本來很愛我的大部分員工因為單據(jù)事件，集體轉(zhuǎn)為黑我恨我了。
3. 公司立馬批了我的計劃，冷備，熱備，異地容災，全部上全了。
4.我揮刀自宮，自己罰了自己，扣除了自己一個月工資。
5.老板到現(xiàn)在還是在懷疑請的那家公司已經(jīng)被我們競爭對手收買，是故意來破壞我們的。
6.萌妹子拉黑了我。
這真是個悲傷的故事。
看完了這個悲傷的故事，我們要回歸理性，MySQL?數(shù)據(jù)庫誤刪除后怎么辦？
然而是人總難免會犯錯誤，說不定哪天大腦短路了，誤操作把數(shù)據(jù)庫給刪除了，怎么辦？下面，就?MySQL 數(shù)據(jù)庫誤刪除后的恢復方案進行說明。
某天早上上班，9 點的時候，一同事犯暈 drop 了一個數(shù)據(jù)庫！
需要緊急恢復！可利用備份的數(shù)據(jù)文件以及增量的 binlog 文件進行數(shù)據(jù)恢復。
用 MySQLbinlog 命令將上述的 binlog 文件導出為 SQL 文件，并剔除其中的 drop 語句。
通過全備文件和增量 binlog 文件的導出 SQL 文件，就可以恢復到完整的數(shù)據(jù)。
首先，要確保?MySQL?開啟了 binlog 日志功能。在 /etc/my.cnf 文件里的 [mysqld] 區(qū)塊添加，如下圖，然后重啟 MySQL 服務。
1.在 ops 庫下創(chuàng)建一張表 customers
-B：指定數(shù)據(jù)庫
-F：刷新日志
-R：備份存儲過程等
-x：鎖表
–master-data：在備份語句里添加 CHANGE MASTER 語句以及 binlog 文件及位置點信息
- 本案例適用于人為 SQL 語句造成的誤操作或者沒有主從復制等的熱備情況宕機時的修復。
- 恢復條件為 MySQL?要開啟 binlog 日志功能，并且要全備和增量的所有數(shù)據(jù)。
- 恢復時建議對外停止更新，即禁止更新數(shù)據(jù)庫。
- 先恢復全量，然后把全備時刻點以后的增量日志，按順序恢復成 SQL 文件，然后把文件中有問題的 SQL 語句刪除（也可通過時間和位置點），再恢復到數(shù)據(jù)庫。
作者：古的白
來源：https://www.zhihu.com/question/30748582/answer/58513703