概述
代码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