MySQL資料庫利用binlog資料恢復

2021-10-10 03:05:47 字數 4512 閱讀 5494

以mysql為例。

binlog是二進位制日誌檔案,使用者記錄使用者對資料庫的操作,各個從庫的同步也是通過binlog,是非常重要的資料庫日誌檔案,其他的關係型資料庫的資料恢復也是大同小異的,例如oracle資料庫可以通過它的歸檔日誌進行恢復。

我們該如何資料恢復?

具體如何恢復資料,要看使用的哪種備份方案,主流的備份方案主要有以下幾種:

全量備份

資料量比較小,全量恢復比較快,例如每天晚上零點進行全量備份,如果想恢復20號以前的資料,直接把20號以前的備份全量恢復就行了

還有一種情況是恢復7號0:00到23:59的資料,這種情況就只能用binlog來恢復了。

全量+增量備份

全量+增量的備份方案適合資料量較大的資料庫,節約磁碟空間,但是全量恢復較慢。如每月1號進行全量備份,後續的每天晚上零點進行增量備份,如果想恢復7號零點以前資料,就只需要恢復1號的全量資料,和2號到7號的增量備份。這種情況如果要恢復7號0:00到23:59的資料也是只能用binlog來恢復。

我們先不討論每一種方案的效率問題,先看一下如果利用binlog進行恢復。

binlog的三種模式:

在mysql5.7.7以前的版本預設模式是statement level,之後預設模式就是row level。

statement level:基於sql語句複製的,只會講sql語句儲存到日誌中,因為這種模式只儲存sql,沒有真正的資料,所以我們無法進行資料恢復。生產環境也一半不用這種模式。

row level:它是基於行的複製,並且會將每一條資料的變化記錄到日誌檔案中,是沒有sql語句的,可以解析出資料,一些生產環境是使用這種模式,但是它也有一定的缺點,比如記錄資料時產生大佬的binlog,面對儲存過程時可能出現資料不一致的情況。

mixed:混合模式,預設情況下是statement模式,某些情況下切換到row模式,結合了row level和statement level的優點,同時binlog結構也更加複雜。

檢視資料庫採用的模式:

以mysql5.7.21為例:

下邊開始嘗試用binlog進行資料解析和恢復了。

先建立一些基礎資料:

root@localhost

(demo)

14:23:31

>

create

table

't1'(-

>

'id'

intnot

null

auto_increment,-

>

'name'

varchar(60

)default

null,-

>

)engine

=innodb

auto_increment=1

default charse=utf8;

query ok,

0rows affected (

0.02 sec)

root@localhost

(demo)

14:23:31

>

insert

into t1(name)

values

('demo1'),

('demo2');

query ok,

2rows affected (

0.00 sec)

records:2duplicates:0

warnings:0

查詢包含插入資料的時間(14:23:31)的binlog檔案

[root@localhost binlog]

# ll mysql-bin.000009

-rw-r----- 1 mysql mysql 837mar 2 14:23 mysql-bin.000009

我們可以看到是mysql-bin.000009檔案,它是乙個二進位制檔案,我們可以用mysql自帶的工具mysqlbinlog進行解析,看看具體的內容

[root@10-0-4-162 binlog]

# /usr/local/mysql/bin/mysqlbinlog --base64-output=decode-rows -v mysql-bin.000009

解析後刪除無關的內容後,正向解析得到的sql和我們先前插入資料的sql一致

......

# at 259

......

create table 't1' (

'id' int not null auto_increment,

'name' varchar(60) default null,

) engine=innodb auto_increment=1 default charse=utf8

......

### insert into `demo`.`t1`

### set

### @1=1

### @2='demo1'

###insert into `demo`.`t1`

###set

### @1=2

### @2='demo2'

commit/*!*/;

......

我們解析資料的目的是恢復資料,例如,將前面的insertsql解析成deletesql語句,因為insert可能是誤插入的資料,如果資料量較小可以手動刪除,如果是生產環境,binlog檔案可能非常大,解析後的sql可能有千萬行,手動修改不太現實,那麼如何生成反向sql呢,我們將介紹兩個資料恢復工具,binlog-rollback和myflash。

我們先用binlog-rollback試一下,其實這就是給perl指令碼。

[root@localhost ~]

# perl binlog-rollback.pl -f '/u01/mysql/3306/log/binlog/mysql-bin.000009' -h 127.0.0.1 -u 'root' -p '1234' -p 3306 -i -o '/tmp/t.sql'

[root@localhost ~]

# more /tmp/t.sql

delete from `demo`

.`t1`

where 'id'

= 2 and `name`

='demo2'

;delete from `demo`

.`t1`

where 'id'

= 1 and `name`

='demo1'

;

可以看的我們之前insert的兩行資料,這裡解析成了delete了,達到了我們恢復資料的目的,當我們誤刪除資料時候,反解的sql就成了insert,這樣就可以達到資料恢復的目的。

我們再來試試myflash工具,這個工具在反解binlog的時候不需要使用者名稱密碼。同時我們也進行了檢視發現確實由insert語句變成了delete。

但是這兩種方式是由差別的,binlog-rollback生成sql,可讀性更好,但是當資料量比較大的時候,myflash就比較快。

[root@localhost myflash-master]

# ./binary/flashback -- binlogfilenames=/u01/mysql/3306/log/binlog/mysql-bin.000009

[root@localhost myflash-master]

# mysqlbinlog --base64-output=decode-rows -v binlog_output_base.flashback

....

..### delete from `demo`.`t1`

### where

### @1=1

### @2='demo1'

###delete from `demo`.`t1`

### where

### @1=2

### @2='demo2'

....

..

總結:正向解析sql我們可以使用mysql自帶的mysqlbinlog,反向解析我們可以使用binlog-rollback和myflash。

利用binlog恢復mysql資料庫資料

前提 mysql資料庫開啟了binlog日誌 通過 show variables like log 檢視是否開啟binlog日誌。操作步驟 在資料庫中執行 show master status 檢視當前資料庫對應的binlog檔案 再執行show binlog events in binlog.00...

C 連線MySQL資料庫(利用API)

一般c c 與資料庫相連有兩種方法。用odbc,ado,jdbc等這些介面,利用裡面的方法來進行與資料庫的連線,簡化對資料庫的操作,方便對資料庫進行管理。不過注意的是c c 也可以用jdbc來與資料庫相連線,不過很彆扭而已。第一種方法,除了安裝所需的資料庫之外,還需要安裝相對應的介面,就是上面所說的...

php資料庫程式設計 利用mysql擴充套件庫運算元據庫。

mysql擴充套件庫是一堆函式.是php設計者提供給程式設計師用於完成對mysql資料庫的各種操作 crud 使用php的mysql擴充套件庫完成對mysql操作的案例 1.編寫php程式完成對使用者表的顯示 mysql擴充套件庫操作mysql資料庫步驟如下 1.獲取連線 conn mysql co...