一直没想到玛雅人跟中国砖家一样不靠谱，本想着趁着世界末日洗手不干了，把钱花光，把信用卡刷爆，把数据库清了。

呜呜。

某库有表40余，所有表执行了truncate以后，5分钟后发现问题，停止业务开始准备恢复数据。

1，确定误操作的时间点
2，确定上次完整备份的时间点

误清操作前五分钟应该没有什么业务量进来，加上数据不重要，将数据恢复到误操作的前几分钟就行，从上次备份的SQL文件顶部，找到了备份操作生成的时间戳，最后，确定了需要恢复数据的时间节点

Date: 2012-12-21 21:20:40
Date: 2012-12-24 20:20:00

进入mysql服务器，找到Binlog文件列表，确定在2012-12-21 21:20:40到2012-12-24 20:20:00时间段内，产生了3个Binlog，分别为2G，1G，10M：

mysql_binglog.00000191
mysql_binglog.00000192
mysql_binglog.00000193

恢复数据的方法有多种，我们使用了一个比较傻的版本。

有直接恢复数据的方法，如
[shell]
mysqlbinlog –start-position=134 –stop-position=330 test mysql_binglog.00000191 | mysql -uroot -p
[/shell]

我们使用的方法是，先将Binlog拆成SQL，确认SQL没有问题，然将需要的SQL的恢复进Mysql
[shell]
mysqlbinlog –start-date="2012-12-21 21:20:40" –stop-date="2012-12-24 20:20:00" mysql_binglog.000191 > back_up_1.sql
mysqlbinlog –start-date="2012-12-21 21:20:40" –stop-date="2012-12-24 20:20:00" mysql_binglog.000192 > back_up_2.sql
mysqlbinlog –start-date="2012-12-21 21:20:40" –stop-date="2012-12-24 20:20:00" mysql_binglog.000193 > back_up_3.sql
[/shell]

二转十以后，发现第三个SQL为空，前两个备份文件里，包含了服务器上所有数据库的增删改SQL，在确定两个SQL文件中没有出现truncate 和 delete *以后，使用导入命令恢复数据

首先将备份的数据导入数据库，再将binlog拆出来的SQL依次导入
[shell]
mysql -u root -p123456 -h192.168.0.1 -f –database=test –default-character-set=utf8 < back_up_2.sql
[/shell]

这个命令里，`–default-character-set=utf8`是指定编码，`-f`是忽略错误，因为是全库的binlog，而我们只需要其中一个库的回滚，其它库不存在表，恢复失败也不在考虑范围内。

最后，将恢复完成的数据库整理并同步到线上。

以前的项目中，出现过单表清空的问题，当时采用的是拆分出Binlog以后，跑脚本将SQL中指定表的SQL拆分出来再导入数据库，不修改其它表的数据，写程序跑文件比较麻烦。