她带着哭腔打电话来（是的，对方做测试的是个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文件中记录的CHANGEMASTER语句，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：在备份语句里添加CHANGEMASTER语句以及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语句删除（也可通过时间和位置点），再恢复到数据库。
作者：古的白
来源：https://www.zhihu.com/question/30748582/answer/58513703
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
