概述
代码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的语句造成，那只能祈祷有备份文件了。
参考