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

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

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

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

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

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

首先我們來創(chuàng)建一個數(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ù)庫進行備份，備份到/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文件及位置點信息

查看備份文件

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

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

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

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

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

flush logs;
show master status;

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

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

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

我們來把xiaozhao刪除掉

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

show master status;

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

我們來查看0009的binlog日志。

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

語法如下

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

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

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

再來查看表

我們發(fā)現(xiàn)xiaozhao又回來了，當然了，這里多了一個xiali，是因為我之前并沒有刪除備份前的數(shù)據(jù)。當然了，我們在恢復的過程中可以選擇只恢復xiaozhao這么一塊內(nèi)容

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

--start-datetime：從二進制日志中讀取指定等于時間戳或者晚于本地計算機的時間

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

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

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

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