實驗環境：

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語句。

再查看表內容

這樣數據就回來了。

到此這篇關于mysql利用mysqlbinlog命令恢復誤刪除數據的實現的文章就介紹到這了,更多相關mysql mysqlbinlog恢復誤刪除內容請搜索腳本之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持腳本之家！