Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 26.8Mb
PDF (A4) - 26.9Mb
HTML Download (TGZ) - 7.1Mb
HTML Download (Zip) - 7.2Mb

7.3.2 リカバリへのバックアップの使用

ここで、水曜日の午前 8 時に、バックアップからのリカバリを必要とする致命的なクラッシュがあったとします。リカバリするには、まず存在する最後の完全バックアップ (日曜日の午後 1 時のもの) をリストアします。完全バックアップファイルは一連の SQL ステートメントにすぎないため、そのリストアはきわめて簡単です。

shell> mysql < backup_sunday_1_PM.sql

この時点で、データは日曜日の午後 1 時現在の状態にリストアされます。それ以降に行われた変更をリストアするには、増分バックアップを使用する必要があります。つまり、gbichot2-bin.000007gbichot2-bin.000008 バイナリログファイルです。必要に応じて、バックアップされた場所からファイルをフェッチして、次のようにそれらの内容を処理します。

shell> mysqlbinlog gbichot2-bin.000007 gbichot2-bin.000008 | mysql

これで、データを火曜日の午後 1 時現在の状態にリカバリしましたが、まだその日からクラッシュの日までの変更が不足しています。それらを失わないために、MySQL サーバーにその MySQL バイナリログを、そのデータファイルを格納している場所と異なる安全な場所 (RAID ディスク、SAN など) に保存させ、これらのログが破損したディスク上にないようにする必要がありました。(つまり、データディレクトリが存在する場所と別の物理デバイス上の場所を指定する --log-bin オプションでサーバーを起動できます。このようにすると、ディレクトリを格納するデバイスが失われてもログは安全です。)これを実行していた場合、gbichot2-bin.000009 ファイル (および任意の後続のファイル) が手元にあるため、mysqlbinlogmysql を使用して、それらを適用し、クラッシュの瞬間まで損失なく、最新のデータの変更をリストアできます。

shell> mysqlbinlog gbichot2-bin.000009 ... | mysql

mysqlbinlog を使用して、バイナリログファイルを処理する詳細については、セクション7.5「バイナリログを使用したポイントインタイム (増分) リカバリ」を参照してください。

User Comments
  Posted by Fred Nurk on July 7, 2009
Beware restoring too many binary logfiles like this.

Each one that you restore will be converted into a temporary file of SQL statements, eg SQL_LOAD_MB-1-0, SQL_LOAD_MB-2-0,
etc. This can easily fill up /tmp.

To work around this, set TMPDIR to some place with lots of space. For extra peace of mind, save the output to a file
instead of feeding it directly to the mysql client. You can
have the client source it when you think you have something reasonable.

TMPDIR=/my/big/disk/tmp; export TMPDIR
mysqlbinlog binlog.* > binlogdump.sql

You will have to clean up the directory afterwards.
Make sure you do this before rerunning mysqlbinlog.

I did this with 6.4G of binlogs. It produced 6.4G of tmpfiles, but a final binlogdmp.sql of only 124Mb.

The other option is to loop over the list of files, appending to binlogdump.sql as you go.
This produces a lot of warnings but a very similar sql file. The differences are not easy to describe succinctly,
but basically the first approach is more robust.

Sign Up Login You must be logged in to post a comment.