今度は、水曜日の午前 8 時に、バックアップからのリカバリが必要な致命的な予期しない終了があるとします。 リカバリするには、まず存在する最後の完全バックアップ (日曜日の午後 1 時のもの) をリストアします。 完全バックアップファイルは一連の SQL ステートメントにすぎないため、そのリストアはきわめて簡単です。
shell> mysql < backup_sunday_1_PM.sql
この時点で、データは日曜日の午後 1 時現在の状態にリストアされます。 それ以降に行われた変更をリストアするには、増分バックアップを使用する必要があります。つまり、gbichot2-bin.000007 と gbichot2-bin.000008 バイナリログファイルです。 必要に応じて、バックアップされた場所からファイルをフェッチして、次のようにそれらの内容を処理します。
shell> mysqlbinlog gbichot2-bin.000007 gbichot2-bin.000008 | mysql
これで、データを火曜日の午後 1 時現在の状態にリカバリしましたが、まだその日からクラッシュの日までの変更が不足しています。 それらを失わないために、MySQL サーバーにその MySQL バイナリログを、そのデータファイルを格納している場所と異なる安全な場所 (RAID ディスク、SAN など) に保存させ、これらのログが破損したディスク上にないようにする必要がありました。 (つまり、データディレクトリが存在する場所と別の物理デバイス上の場所を指定する --log-bin オプションでサーバーを起動できます。 このようにすると、ディレクトリを格納するデバイスが失われてもログは安全です。) これを実行していた場合、gbichot2-bin.000009 ファイル (および任意の後続のファイル) が手元にあるため、mysqlbinlog と mysql を使用して、それらを適用し、クラッシュの瞬間まで損失なく、最新のデータの変更をリストアできます。
shell> mysqlbinlog gbichot2-bin.000009 ... | mysqlmysqlbinlog を使用して、バイナリログファイルを処理する詳細については、セクション7.5「Point-in-Time (増分) リカバリ」を参照してください。