概述

　　代码bug，在处理上传出现异常时执行了DELETE FROM t_resource WHERE resource_id = ? OR parent_id = ？因为OR条件导致用户的上传的所有数据被清空了。

show

　　查看是否有开启log-bin备份

show variables like 'log_bin'

 

 欣慰的是，已经开启了二进制日志备份。那接下来就简单多了，找到这个二进制日志，找到这个节点，去恢复它。执行这个命令，查看正在写入的二进制日志是哪个文件

show master status

 当然也可以flush重新开始一个文件写入。用这个文件名在Linux全局搜下这个文件在哪==> find / -name mysql,找到这么久好办了。

mysqlbinlog

mysqlbinlog -vv --start-datetime='2019-9-24 11:24:00' --stop-datetime='2019-9-24 11:25:20' mysql-bin.000211| grep "t_resource" | more

查看里面执行删除操作的pos位置

 

 然后去查看从哪里开始执行了删除

show binlog events in 'mysql-bin.000211'

 

 知道了开始和结束的节点，恢复数据就很快了，因为logbin是二进制日志，我们把它弄成我们看得懂的

mysqlbinlog -vv --start-position=956859551 --stop-position=956863056 mysql-bin.000211 |grep ^"###" >bin_1448

就生成了一个bin_1448文件。我们打开看下

 

 这个就是执行delete删除的东西

INSERT

接下去就是把它反过去变成insert语句就OK了

cat bin_1448 | sed -n '/###/p' | sed 's/### //g;s/\/\*.*/,/g;s/DELETE FROM/INSERT INTO/g;s/WHERE/SELECT/g;' |sed -r 's/(@6.*),/\1;/g' | sed 's/@[1-9]=//g' | sed 's/@[1-9][0-9]=//g' >resource.sql

打开，resource.sql 就是我们很多眼熟的sql语句了。。调整执行就很简单了

 

 总结

　　以上只能对delete的误操作有效，而且binlog是行模式，如果是truncate的语句造成，那只能祈祷有备份文件了。

参考

https://yq.aliyun.com/articles/664444