关于使用Mysql binlog对数据进行恢复的实战

    前几天，加班到晚上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点半了，收工，回家……