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

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

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

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

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

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

大體思路如下：

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ù)目錄下， 啟動一個空實(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-56SHOW SLAVE STATUSG；

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

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