概述

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

?

轉載于:https://www.cnblogs.com/dslx/p/11578972.html

總結

以上是生活随笔為你收集整理的mysqlbinlog恢复误删数据的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。