MySQLある時点までのリカバリ

k2snow

11年前

DBの復旧パターンって状況によって操作が変わってくると思います。想定される状況に応じてしっかり対応できるように手順を把握して、いざ障害でリカバリが必要になった場合でも、あたふたしたり心臓バクバクせずに冷静に対処したいっす。
今回は操作ミスでデータが消失し、DBをある時点(データ消失する直前)まで戻す必要が発生した場合を想定します。
MySQL5.5で確認。
バックアップとバックアップ以後のバイナリログがあることが前提です。

1.前回のmysqldumpで取得したバックアップのCHANGE MASTERを確認して、バイナリログのどのポジションから当てればいいか確認。

# less /backup/yyyymmdd.mysqldump.sql

-- CHANGE MASTER TO MASTER_LOG_FILE='binary.000006', MASTER_LOG_POS=107;

*バイナリログはbinary.000006でポジション107から開始する。
前回mysqldumpのオプション--flush-logsを指定して、スイッチしたバイナリログがbinary.000006なのでポジション指定しないで先頭から開始していいはず。
なぜ先頭ポジション(4)が表示されないのかは不明なので宿題…

2.バックアップファイルで前回のバックアップ時点までリストアする。

# mysql -uroot -p < /backup/yyyymmdd.mysqldump.sql

3.バイナリログをmysqlbinlogコマンドでテキスト形式のSQL文に変換する。

対象バイナリログ
・binary.000006
・binary.000007　※このバイナリログがカレントの時に操作ミスが発生

--binary.000006はmysqldumpの--flush-logsでスイッチしたバイナリログなので先頭から適用します
# mysqlbinlog binary.000006 > recovery.000006

--binary.000007は先頭から適用するので--start-positionは無くてもよいです
--操作ミスが発生したポジション23901で停止
# mysqlbinlog --start-position=4 --stop-position=23901 binary.000007 > recovery.000007

--時間で指定する場合
# mysqlbinlog --stop-datetime=”2014-04-20 00:58:00″ binary.000007 > recovery.000007

4.mysqlbinlogで変換したファイルを適用する。

# mysql -uroot -p < recovery.000006
# mysql -uroot -p < recovery.000007

今回マスターで確認しましたが、スレーブ側がどうなっているか確認したところ問題なくレプリケーションされているようでした。

■master

mysql> show master status\G
*************************** 1. row ***************************
            File: binary.000007
        Position: 5408410

■slave

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: xxx.xxx.xxx.xxx
                  Master_User: xxx
                  Master_Port: xxxx
                Connect_Retry: xx
              Master_Log_File: binary.000007
          Read_Master_Log_Pos: 5408410

参考
7.9. mysqlbinlog — バイナリログファイルを処理するためのユーティリティ
MySQL バイナリログを使ったデータリカバリ
http://open-groove.net/mysql/mysql-time-base-recovery/