1. 程式人生 > >mysql利用mysqlbinlog命令恢復誤刪除資料

mysql利用mysqlbinlog命令恢復誤刪除資料

實驗環境:

MYSQL 5.7.22 

開啟二進志日誌

日誌格式MIXED

實驗過程:

1、執行:FLUSH LOGS;

master-bin.000014 檔案就是新生成的檔案

重新整理日誌是為了實驗內容更直觀,更容易觀察到整個實驗過程的內容。

我看到網上許多文章有在用REST MASTER;而未說明此命令的嚴重性

這條命令會刪除所有日誌檔案,並將檔名和記錄點進行重置歸零,99%的情況下是用不到這條命令的

刪除日誌可以用PURGE MASTER LOGS...這樣保險一點

2、新日誌檔案已經生成,先觀察一下內容,有幾個點需要了解

檢視二進日日誌檔案命令:mysqlbinlog master-bin.000014

# at 4
#180903 16:19:12 server id 1  end_log_pos 123 CRC32 0xe03659b3  Start: binlog v 4, server v 5.7.22-log created 180903 16:19:12

先看上邊兩個箭頭:

# at 4(事件開始點)

#180903 16:19:12 (代表的是時間)

server id 1(主備複製時需要為每個MYSQL資料庫指定唯一的SERVER ID,我的未配置,預設是1)

end_log_pos 123(事件結束點)

再看下邊兩個箭頭:

# at 123(事件開始點,和上邊的事件結束點是對應的)

end_log_pos 154(事件結束點)

at 4 和 at 123之間的內容就是事件內容

3、模擬業務場景,建表,插入資料,最後將某個表刪除;為了真實,我建了兩個庫,同時向不同的庫寫入內容,最後將其中一個庫中的某個表刪除。

mysql> FLUSH LOGS;
Query OK, 0 rows affected (0.01 sec)

mysql> create database t1;
Query OK, 1 row affected (0.03 sec)

mysql> create database t2;
Query OK, 1 row affected (0.00 sec)

mysql> use t1;
Database changed
mysql> create table t1 (id int);
Query OK, 0 rows affected (0.03 sec)

mysql> use t2;
Database changed
mysql> create table t2 (id int);
Query OK, 0 rows affected (0.03 sec)

mysql> insert into t2 values (3);
Query OK, 1 row affected (0.01 sec)

mysql> insert into t2 values (4);
Query OK, 1 row affected (0.01 sec)

mysql> use t1;
Database changed
mysql> insert into t1 values (1);
Query OK, 1 row affected (0.01 sec)

mysql> insert into t1 values (2);
Query OK, 1 row affected (0.01 sec)

mysql> use t2;
Database changed
mysql> insert into t2 values(20);
Query OK, 1 row affected (0.01 sec)

mysql> use t1;
Database changed
mysql> insert into t1 values(10);
Query OK, 1 row affected (0.01 sec)

mysql> drop table t1;
Query OK, 0 rows affected (0.02 sec)

mysql> use t2;
Database changed
mysql> insert into t2 values(222);
Query OK, 1 row affected (0.01 sec)

mysql>

建立T1、T2庫,建立T1、T2表。

向T1插入資料:1、2、10

向T2插入資料:3、4、20、222

模擬場景,刪除T1表,T2庫T2表業務還在繼續執行

現在將要通過日誌將T1表進行恢復。

首先要先找到那個刪除命令的日誌點:

mysqlbinlog master-bin.000014|grep -5a "DROP TABLE"

看到#AT 2439 (記下這個數字)

在這個事件點執行的DROP TABLE操作。

由於日誌檔案內不只有T1庫的日誌,還有T2庫的日誌,一會只取T1資料庫的日誌

而且還只取2439日誌點之前的日誌,再進行重新應用

如果把2439的日誌取的話,再應用時資料庫會重新建庫建表,插資料, 還會執行這條刪表語句。

 mysqlbinlog -d t1 --stop-position=2439  master-bin.000014>test.sql(執行這條語句竟然報錯了)

WARNING: The option --database has been used. It may filter parts of transactions, but will include the GTIDs in any case. If you want to exclude or include transactions, you should use the options --exclude-gtids or --include-gtids, respectively, instead.
暫時弄不清楚原因,百度了下修改成:

mysqlbinlog master-bin.000014 -d t1  --skip-gtids --stop-position=2439>test.sql

-d:引數是指定某個資料庫日誌 

命令意思是將master-bin.000014日誌檔案內的T1資料庫日誌,事件點2439之前的日誌,輸出到test.sql

# tail test.sql

看看檔案最後幾行

登入資料庫:

mysql> use t1;
Database changed

mysql> source test.sql

中間報錯了一次,因為裡邊包含建庫T1語句。

再查看錶內容

這樣資料就回來了。