MySQL的binlog日志是MySQL日志中非常重要的一種日志，記錄了數(shù)據(jù)庫所有的DML操作。通過binlog日志我們可以進(jìn)行數(shù)據(jù)庫的讀寫分離、數(shù)據(jù)增量備份以及服務(wù)器宕機(jī)時(shí)的數(shù)據(jù)恢復(fù)。

定期備份固然可以在服務(wù)器發(fā)生宕機(jī)的時(shí)候快速的恢復(fù)數(shù)據(jù)，但傳統(tǒng)的全量備份不可能做到實(shí)時(shí)，所以在發(fā)生宕機(jī)的時(shí)候，也會損傷一部分?jǐn)?shù)據(jù)，如果這個(gè)時(shí)候開啟了binlog日志，那么可以通過binlog來對沒有做備份的這一階段損失的數(shù)據(jù)進(jìn)行恢復(fù)。如果了解Redis的朋友，可能想到了，Redis有兩種持久化方式，分別是AOF和RDB。RDB就類似于MySQL的全量復(fù)制，AOF就類似于MySQL的binlog。

關(guān)于數(shù)據(jù)的恢復(fù)這里在說一點(diǎn)，既然binlog這么好，是不是開啟了binlog就不需要定期做備份了呢，不要這樣做。為什么呢，因?yàn)閎inlog的數(shù)據(jù)量非常大，另外就是使用binlog做數(shù)據(jù)的恢復(fù)性能會非常低。因?yàn)閎inlog是對操作的記錄，比如某一時(shí)刻，我先插入了一條數(shù)據(jù)，然后將這條數(shù)據(jù)刪除了，本身數(shù)據(jù)是沒了，但有兩條操作。如果是全量備份，肯定沒有這條數(shù)據(jù)，如果使用binlog需要執(zhí)行一條插入和一條刪除操作，因此性能和文件大小都是比較大的。

啰嗦了一堆，下面說關(guān)于數(shù)據(jù)恢復(fù)的問題：

在正式開始之前，先來說一說mysql完整備份數(shù)據(jù)庫，以及恢復(fù)數(shù)據(jù)庫的方法

備份數(shù)據(jù)庫：

首先我們來創(chuàng)建一個(gè)數(shù)據(jù)庫，mytest

create database mytest;

接著我們來創(chuàng)建一張表

use mytest;
create table t1(id int ,name varchar(20));

然后我們插入兩條數(shù)據(jù)

insert into t1 values (1,'xiaoming');
insert into t1 values (2,'xiaohong');

下面我們對mytest數(shù)據(jù)庫進(jìn)行備份，備份到/root/bakup/

mysqldump -uroot -p -B -F -R -x --master-data=2 mytest | gzip > /root/backup/bak_$(date +%F).sql.gz

參數(shù)說明：

-B：指定數(shù)據(jù)庫

-F：刷新日志

-R：備份存儲過程等

-x：鎖表

--master-data：在備份語句里添加CHANGE MASTER語句以及binlog文件及位置點(diǎn)信息

查看備份文件

這樣呢，我們就把數(shù)據(jù)做了一個(gè)完整的備份。下面來刪除數(shù)據(jù)庫，然后通過備份數(shù)據(jù)進(jìn)行恢復(fù)數(shù)據(jù)庫。

gzip -d bakup_xxx.gz
mysql -uroot -p < bakup_xxx.sql

這樣我們就把數(shù)據(jù)導(dǎo)入到庫里了。

繼續(xù)上面的操做，我們新增xiaoli和xiaozhao這兩條數(shù)據(jù)，并把xiaozhao這條記錄刪除掉。

在刪除之前，我們先來刷新binlog日志，生成一個(gè)新的日志，那么我們之后所要操做的內(nèi)容都會被記錄到新的日志文件中。（通過前面binlog日志的詳細(xì)說明我們知道，每次刷新和服務(wù)重啟的時(shí)候，都會生成一個(gè)binlog日志文件。）

flush logs;
show master status;

我們注意，binlog的文件是0009，位置是在154，這兩個(gè)信息很重要

下面我們來做插入和刪除操作

這個(gè)時(shí)候我們應(yīng)該是來查看一下binlog日志的狀態(tài)，以便與我們一會來進(jìn)行恢復(fù)到此狀態(tài)，但是，真正的環(huán)境中我們并不知道這個(gè)狀態(tài)，因此這里也就不去查看這個(gè)狀態(tài)了，這個(gè)狀態(tài)的值可以通過后面查看binlog日志文件來進(jìn)行分析。下面我們開始誤操作：

我們來把xiaozhao刪除掉

這樣數(shù)據(jù)就刪除掉了，下面我們再來查看binlog的狀態(tài)

show master status;

這個(gè)時(shí)候我們發(fā)現(xiàn)我刪除操作是個(gè)錯誤的操作，要進(jìn)行恢復(fù)，那么該如何恢復(fù)呢？這個(gè)時(shí)候我們就可以通過binlog的position來進(jìn)行恢復(fù)。
在進(jìn)行其他的處理之前，我們建議，馬上再執(zhí)行一次flush logs，也就是讓出錯的部分就集中在這么一個(gè)binlog日志文件中。

我們來查看0009的binlog日志。

我們看到delete_rows 結(jié)束點(diǎn)是928這個(gè)點(diǎn)，起始點(diǎn)是在755這個(gè)點(diǎn)，我們可以把操作的這些數(shù)據(jù)刪除到我們上次備份的內(nèi)容，然后通過執(zhí)行binlog來進(jìn)行恢復(fù)，當(dāng)然恢復(fù)到755這個(gè)點(diǎn)之前。
比如我上次備份的是整個(gè)數(shù)據(jù)庫，我就可以把整個(gè)數(shù)據(jù)庫刪除，然后通過備份文件恢復(fù)，然后再通過binlog做增量恢復(fù)。這樣數(shù)據(jù)就回來了。這里就不再進(jìn)行刪庫了，我們直接演示使用binlog日志恢復(fù)數(shù)據(jù)的方法

語法如下

mysqlbinlog mysql-bin.0000xx | mysql -u用戶名 -p密碼 數(shù)據(jù)庫名

比如我們要把所有的操作都恢復(fù)（不包括我們的刪除，我們知道刪除是在755點(diǎn)上）：

mysqlbinlog mysql-bin.000009 --start-position 154 --stop-position 755 | mysql -uroot -p mytest

再來查看表

我們發(fā)現(xiàn)xiaozhao又回來了，當(dāng)然了，這里多了一個(gè)xiali，是因?yàn)槲抑安]有刪除備份前的數(shù)據(jù)。當(dāng)然了，我們在恢復(fù)的過程中可以選擇只恢復(fù)xiaozhao這么一塊內(nèi)容

下面是binlog日志恢復(fù)中一些常用的參數(shù) 

--start-datetime：從二進(jìn)制日志中讀取指定等于時(shí)間戳或者晚于本地計(jì)算機(jī)的時(shí)間

--stop-datetime：從二進(jìn)制日志中讀取指定小于時(shí)間戳或者等于本地計(jì)算機(jī)的時(shí)間 取值和上述一樣

--start-position：從二進(jìn)制日志中讀取指定position 事件位置作為開始。

--stop-position：從二進(jìn)制日志中讀取指定position 事件位置作為事件截至

到此這篇關(guān)于MySQL使用binlog日志做數(shù)據(jù)恢復(fù)的實(shí)現(xiàn)的文章就介紹到這了,更多相關(guān)MySQL binlog數(shù)據(jù)恢復(fù)內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論