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