6.3 マスターデータベースのリストア

レプリケーションマスターデータベースの破損の問題を修正するには、不要な SQL 操作がスレーブサーバーに伝播されないように注意して、バックアップをリストアできます。

1. マスターデータベースのバックアップを使用して、apply-log 操作を実行し、データベースをシャットダウンして、copy-back 操作を実行します。

2. スレーブでマスターのリカバリに必要なバイナリログを 2 回受け取ることにないように、マスター my.cnf ファイルを編集し、log-bin のコメントを解除します。

3. バイナリログをマスターにパイプしている間、一時的にスレーブのレプリケーションが停止する必要があります。スレーブで、次を実行します。

   mysql> STOP SLAVE;

4. リストアされたバックアップで、マスター mysqld を起動します。

   $ mysqld
   …
   InnoDB: Doing recovery: scanned up to log sequence number 0 64300044
   InnoDB: Last MySQL binlog file position 0 5585832, file name
   ./omnibook-bin.002
   …

   InnoDB はバイナリログファイル (この場合 ./omnibook-bin.002) とリカバリできた位置 (この場合 5585832) を出力します。

5. バイナリログファイルの残りをリストアされたバックアップにパイプします。たとえば、omnibook-bin.002 の後に生成された 2 つの追加のバイナリログファイル omnibook-bin.003 および omnibook-bin.004 がある場合、サーバーへの単一の接続で、それらすべてをパイプします (mysqlbinlog の使用の詳細については、「バイナリログを使用したポイントインタイム (増分) リカバリ」を参照してください)。

   $ mysqlbinlog --start-position=5585833 /mysqldatadir/omnibook-bin.002 \
     /mysqldatadir/omnibook-bin.003 /mysqldatadir/omnibook-bin.004 | mysql

   残りのバイナリログファイルの数は、最後のバックアップからデータベースを最新にしたいと考える時間までの期間の長さによって異なります。期間が長いほど、多くの残りのバイナリログファイルが存在します。リストアの成功には、その期間のすべての連続したバイナリログの位置を含むすべてのバイナリログファイルが必要です。

6. これでマスターデータベースがリカバリされます。マスターをシャットダウンし、my.cnf を編集して、log-bin のコメントを解除します。

7. 再度マスターを起動します。

8. スレーブで再度レプリケーションを起動します。

   mysql> START SLAVE;