人生大起大落落落落落落，实在是太刺激了，下面这真是一个悲伤的故事。
那年公司 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 语句删除(也可通过时间和位置点)，再恢复到数据库。
