レプリケーションマスターデータベースの破損の問題を修正するには、不要な SQL 操作がスレーブサーバーに伝播されないように注意して、バックアップをリストアできます。
マスターデータベースのバックアップを使用して、
apply-log
操作を実行し、データベースをシャットダウンして、copy-back
操作を実行します。スレーブでマスターのリカバリに必要なバイナリログを 2 回受け取ることにないように、マスター
my.cnf
ファイルを編集し、log-bin
のコメントを解除します。-
バイナリログをマスターにパイプしている間、一時的にスレーブのレプリケーションが停止する必要があります。スレーブで、次を実行します。
mysql> STOP SLAVE;
-
リストアされたバックアップで、マスター 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
) を出力します。 -
バイナリログファイルの残りをリストアされたバックアップにパイプします。たとえば、
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
残りのバイナリログファイルの数は、最後のバックアップからデータベースを最新にしたいと考える時間までの期間の長さによって異なります。期間が長いほど、多くの残りのバイナリログファイルが存在します。リストアの成功には、その期間のすべての連続したバイナリログの位置を含むすべてのバイナリログファイルが必要です。
これでマスターデータベースがリカバリされます。マスターをシャットダウンし、
my.cnf
を編集して、log-bin
のコメントを解除します。再度マスターを起動します。
-
スレーブで再度レプリケーションを起動します。
mysql> START SLAVE;