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

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

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

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

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

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

    大體思路如下：

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

    具體的步驟如下：

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

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

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

    如果啟動正常，則連接mysql，查看binlog相關信息：

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

 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；

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

以上就是MySQL 基于時間點的快速恢復方案的詳細內容，更多關于MySQL 快速恢復的資料請關注腳本之家其它相關文章！

最新評論