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