前几天，加班到晚上10点多了，在回去的路上，朋友打来电话，说他们公司的开发维护人员在对线上系统进行版本更新时，不小心把线上的数据库给drop掉了，叫我过去救火，唉！ 虽然在运维界也混迹多年，这情况也是头一回见哈，怀着即兴奋又担心的心情去到现场，兴奋是因为可以好好的实战一下，担心是怕帮不到朋友，唉，废话不多说，上“战场”。
第一步，既然数据库都被干掉了，又没做主从，只好把所有相关系统程序关闭。
第二步，查看一下每天一备的包，万幸，凌晨3点半的时候，有做了一份全备，备份是方式是tar包整个目录，binlog功能也有开着，今天的binlog日志还在。马上把tar包解压出来，这里省略一万个字，才50GB的包，解压花了将近1个小时的时间，只想说某宝的云主机，硬盘读写真是一个坑。
第三步，校验一下备份的看能不能用，为了省时间，直接把解压出来的库文件夹，直接MV到mysql datadir 下，把mysql 启起来，select 某个表的数据，提示表不存在，汗，难道备份的数据有问题，汗水都流出来了，show engines,查看引擎，再查看了一下my.ini，哈哈，原来用的是InnoDB引擎，不能直接单独mv库文件夹，不管了，直接把整个备份的文件夹直接MV过来，再校验了一下数据，凌晨3点半之前的数据都完整无缺，这时候，心情才开始美丽了一些，就算找不回DROP掉的数据，至少大部分的数据没问题了，只少了今天凌晨3点半之后到晚上10点这大半天的数据。
第四步，找到今天的binlog日志，对比了一下时间，找到那个mysql_bin.0000XX,直接cp到tmp目录下，输入该命令：mysqlbinlog --start-date="2016-01-20 03:30:00" --stop-date="2016-01-20 22:00:00" mysql_bin.0000xx > /tmp/test.sql，很快，sql语句就转出来了，直接VIM看了一下最后一条sql语句，确认没有drop database语句。
第五步，登录mysql，直接source /tmp/test.sql；等了15分钟吧，恢复完了，让他们确认了下数据有没有问题，最后确认没问题，至此，凌晨2点半了，收工，回家……