概述

　　代碼bug，在處理上傳出現(xiàn)異常時(shí)執(zhí)行了DELETE FROM t_resource WHERE resource_id = ? OR parent_id = ？因?yàn)镺R條件導(dǎo)致用戶的上傳的所有數(shù)據(jù)被清空了。

show

　　查看是否有開(kāi)啟log-bin備份

show variables like 'log_bin'

?

?欣慰的是，已經(jīng)開(kāi)啟了二進(jìn)制日志備份。那接下來(lái)就簡(jiǎn)單多了，找到這個(gè)二進(jìn)制日志，找到這個(gè)節(jié)點(diǎn)，去恢復(fù)它。執(zhí)行這個(gè)命令，查看正在寫(xiě)入的二進(jìn)制日志是哪個(gè)文件

show master status

?當(dāng)然也可以flush重新開(kāi)始一個(gè)文件寫(xiě)入。用這個(gè)文件名在Linux全局搜下這個(gè)文件在哪==> 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

查看里面執(zhí)行刪除操作的pos位置

?

?然后去查看從哪里開(kāi)始執(zhí)行了刪除

show binlog events in 'mysql-bin.000211'

?

?知道了開(kāi)始和結(jié)束的節(jié)點(diǎn)，恢復(fù)數(shù)據(jù)就很快了，因?yàn)閘ogbin是二進(jìn)制日志，我們把它弄成我們看得懂的

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

就生成了一個(gè)bin_1448文件。我們打開(kāi)看下

?

?這個(gè)就是執(zhí)行delete刪除的東西

INSERT

接下去就是把它反過(guò)去變成insert語(yǔ)句就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

打開(kāi)，resource.sql 就是我們很多眼熟的sql語(yǔ)句了。。調(diào)整執(zhí)行就很簡(jiǎn)單了

?

?總結(jié)

　　以上只能對(duì)delete的誤操作有效，而且binlog是行模式，如果是truncate的語(yǔ)句造成，那只能祈禱有備份文件了。

參考

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

?

轉(zhuǎn)載于:https://www.cnblogs.com/dslx/p/11578972.html

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。