mysql误清数据恢复手记

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

呜呜。

某库有表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

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

有直接恢复数据的方法,如

mysqlbinlog --start-position=134 --stop-position=330 test mysql_binglog.00000191 | mysql -uroot -p

我们使用的方法是,先将Binlog拆成SQL,确认SQL没有问题,然将需要的SQL的恢复进Mysql

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

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

首先将备份的数据导入数据库,再将binlog拆出来的SQL依次导入

mysql -u root -p123456 -h192.168.0.1 -f --database=test --default-character-set=utf8 < back_up_2.sql

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

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

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

发表评论

电子邮件地址不会被公开。