之所以有這樣一篇文章，是因?yàn)樵谇皫滋斓囊粋€(gè)晚上，要下班的時(shí)候，業(yè)務(wù)方忽然有一個(gè)需求，是需要恢復(fù)一個(gè)表里面的數(shù)據(jù)，當(dāng)時(shí)問了下情況，大概是這樣的：業(yè)務(wù)方不小心在一個(gè)表里面做了一個(gè)update的操作，可能是where條件沒有寫對，導(dǎo)致表里面的數(shù)據(jù)被寫壞了，但是數(shù)據(jù)目前還沒有落盤，只是在內(nèi)存中的值修改了，現(xiàn)在要求恢復(fù)到之前的數(shù)據(jù)。萬幸，這份數(shù)據(jù)是平臺上某些商品的價(jià)格，基本上是有限個(gè)商品，然后價(jià)格值也都是固定的，之前有對這個(gè)價(jià)格表進(jìn)行備份，于是給他直接重新導(dǎo)入了一份價(jià)格表的數(shù)據(jù)，這個(gè)問題也算是解決了。

    當(dāng)時(shí)我在想，如果我沒有備份，只有binlog，這個(gè)時(shí)候如果這個(gè)問題讓我來恢復(fù)，那么有什么更好的辦法么？新建一個(gè)實(shí)例，全庫還原，然后應(yīng)用備份的binlog，一直去追，追到數(shù)據(jù)被該壞的時(shí)間點(diǎn)。

 使用mysqlbinlog工具重放事務(wù)，這種方法會有很多陷阱，比如：

     1、只能每次運(yùn)行一個(gè)mysqlbinlog命令，一次對一個(gè)binlog文件執(zhí)行重放，無法并行多命令運(yùn)行，因?yàn)樵趫?zhí)行重放的時(shí)候會產(chǎn)生一個(gè)臨時(shí)表，會有沖突，造成失敗。

     2、它是一個(gè)原子操作。如果它在運(yùn)行到半途中間的時(shí)候失敗，將很難知道它在哪失敗，也很難基于先前的時(shí)間點(diǎn)重新開始。導(dǎo)致失敗的理由會有很多：一些并發(fā)事務(wù)引起的Innodb lock wait timeout ，server和client設(shè)置的max_allowed_packet不同，以及查詢過程中失去跟mysql server的連接，等等。

    于是翻了翻percona的博客，找到一種方法，看了看精髓，就大概記錄了下來，這兒方法我還沒有親自實(shí)現(xiàn)，只是記錄在這里，以后有時(shí)間了可以親自操作一把，看看是否能夠比較高效的解決這個(gè)問題。

    大體思路如下：

 2臺額外機(jī)器，第1臺用于做備份結(jié)果數(shù)據(jù)的恢復(fù)，另外1臺用于將原主的binlog拷貝至該實(shí)例然后模擬原主，然后第一臺與第二臺建立主從關(guān)系，change master to 第二臺，位置點(diǎn)位備份結(jié)果（xtrabackup_binlog_info中的binlog名和pos），然后同步至誤操作點(diǎn)停止，將恢復(fù)的表，導(dǎo)出，然后恢復(fù)至生產(chǎn)原主。

    具體的步驟如下：

1、準(zhǔn)備一臺機(jī)器，用于將該實(shí)例的最新備份的結(jié)果數(shù)據(jù)，進(jìn)行備份還原

2、準(zhǔn)備另外一臺機(jī)器了，新實(shí)例，將原master的binlog文件，拷貝至該實(shí)例的數(shù)據(jù)目錄下， 啟動一個(gè)空實(shí)例（server-id跟原主一致， --log_bin=master-bin  binlog文件名保持跟原主一致；），然后停掉它，刪除所有它自動創(chuàng)建的binlogs，解壓縮并拷貝所有需要的binlogs(來自于原生產(chǎn)實(shí)例)到它的數(shù)據(jù)目錄下，然后重新啟動它。

    最新備份數(shù)據(jù)的位置：

    如果啟動正常，則連接mysql，查看binlog相關(guān)信息：

3、建立同步關(guān)系，并同步到誤操作動作的位置前停止

 CHANGE MASTER TO 

MASTER_HOST='127.0.0.1',

MASTER_PORT=3307,

MASTER_USER='root',

MASTER_PASSWORD='secret',

MASTER_LOG_FILE='master-bin.000007', MASTER_LOG_POS=1518932;

START SLAVE UNTIL 

MASTER_LOG_FILE = 'log_name', 

MASTER_LOG_POS = log_pos 

或者

START SLAVE SQL_THREAD UNTIL

 SQL_AFTER_GTIDS =

 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56

SHOW SLAVE STATUSG；

    相當(dāng)于多用了一臺實(shí)例，提高二進(jìn)制日志的利用速率，提高二進(jìn)制日志的利用的成功率。這個(gè)方法是否可行，還有待驗(yàn)證，按照文章中作者講述的思想來看，是比單實(shí)例應(yīng)用binlog的方法好，因?yàn)橐坏┌l(fā)生了應(yīng)用binlog過程中的錯(cuò)誤，它能夠快速確定實(shí)在那個(gè)點(diǎn)位發(fā)生的錯(cuò)誤，有助于我們快速解決問題。

以上就是MySQL 基于時(shí)間點(diǎn)的快速恢復(fù)方案的詳細(xì)內(nèi)容，更多關(guān)于MySQL 快速恢復(fù)的資料請關(guān)注腳本之家其它相關(guān)文章！