共计 3571 个字符，预计需要花费 9 分钟才能阅读完成。
人生大起大落落落落落落，实在是太刺激了，下面这真是一个悲伤的故事。
那年公司 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 数据库误删除后的恢复方案进行说明。
某天早上上班，9 点的时候，一同事犯晕 drop 了一个数据库！
需要紧急恢复！可利用备份的数据文件以及增量的 binlog 文件进行数据恢复。
用 MySQLbinlog 命令将上述的 binlog 文件导出为 SQL 文件，并剔除其中的 drop 语句。
通过全备文件和增量 binlog 文件的导出 SQL 文件，就可以恢复到完整的数据。
首先，要确保 MySQL 开启了 binlog 日志功能。在 /etc/my.cnf 文件里的 [mysqld] 区块添加，如下图，然后重启 MySQL 服务。
1. 在 ops 库下创建一张表 customers
-B：指定数据库
-F：刷新日志
-R：备份存储过程等
-x：锁表
–master-data：在备份语句里添加 CHANGE MASTER 语句以及 binlog 文件及位置点信息
- 本案例适用于人为 SQL 语句造成的误操作或者没有主从复制等的热备情况宕机时的修复。
- 恢复条件为 MySQL 要开启 binlog 日志功能，并且要全备和增量的所有数据。
- 恢复时建议对外停止更新，即禁止更新数据库。
- 先恢复全量，然后把全备时刻点以后的增量日志，按顺序恢复成 SQL 文件，然后把文件中有问题的 SQL 语句删除（也可通过时间和位置点），再恢复到数据库。
作者：古的白
来源：https://www.zhihu.com/question/30748582/answer/58513703
