万が一に備えて、定期的にバックアップを取る必要があります。MySQL では、いくつかのツールを使用して、フル バックアップ (ある時点でのデータのスナップショット) を取ることができます。たとえば、InnoDB Hot Backup を使用すると、オンラインでブロックしていない InnoDB データ ファイルのフィジカル バックアップ (物理的) が取れ、 mysqldump を使用すると、オンラインのロジカル バックアップ (理論的) を取ることができます。このセクションでは、mysqldump について説明します。

MySQL Enterprise.  MySQL Network Monitoring and Advisory Service では、バックアップとレプリケーションに関する専門的なアドバイスを提供しています。詳細はhttp://www-jp.mysql.com/products/enterprise/advisors.html を参照してください。

負荷が少ない日曜の午後 1 時にバックアップを取ると仮定します。次のコマンドで、すべてのデータベースの InnoDB テーブルすべてをフル バックアップします。

shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql

これは、オンラインのバックアップをブロックしていない場合のため、テーブルの読み書き込みには影響しません。ここでは、バックアップ対象のテーブルが InnoDB であると仮定しているため、--single-transaction オプションでは整合性のあるデータ読み込みになり、mysqldump で使用したデータは変更しません。(クライアントによる InnoDB テーブルへの変更は、mysqldump プロセスで対象になっていません。) 異なる種類のテーブルもある場合には、そのテーブルがバックアップ中に変更しないものとします。たとえば、mysql データベースの MyISAM テーブルでは、バックアップ中に管理系の変更を MySQL のアカウントに対して行っていないものとします。

mysqldump による .sql ファイルには、後で使用するテーブル ダンプのリロードに使用する SQL INSERT ステートメントのセットが入ります。

フル バックアップは不可欠ですが、時間を要します。大きなバックアップ ファイルの生成には時間がかかります。前回のフル バックアップを行ってから全く変更のない部分も含めて、すべてのデータをフル バックアップを何度も行うことは最適化とはいえません。一度、フル バックアップを行ったら、次からは、インクリメント バックアップを行う方が効率的です。この方法であれば、負荷も減り、生成にかかる時間も短縮できます。トレードオフとしては、リカバリを行うときに、フル バックアップをリロードするだけではデータの回復にはならない、増加分にはインクリメント バックアップも使用して回復しなければならないという良し悪しがあります。

インクリメント バックアップを行うには、増加分/変更分 (インクリメント) を保存する必要があります。これには、MySQL サーバを常に --log-bin オプションで起動する必要があり、これにより、データ更新中に合わせて変更をファイルに保存できます。このオプションはバイナリ ロギングを可能にするものであるため、サーバは MySQL バイナリ ログというファイルに、データ更新に関するそれぞれの SQL ステートメントを書き込みます。ここで、数日間実行していた MySQL バイナリ ログ ファイルの例を次に示します。これは--log-bin オプションで起動した MySQL サーバのデータ ディレクトリのものです。

-rw-rw---- 1 guilhem  guilhem 1277324 Nov 10 23:59 gbichot2-bin.000001
-rw-rw---- 1 guilhem  guilhem       4 Nov 10 23:59 gbichot2-bin.000002
-rw-rw---- 1 guilhem  guilhem      79 Nov 11 11:06 gbichot2-bin.000003
-rw-rw---- 1 guilhem  guilhem     508 Nov 11 11:08 gbichot2-bin.000004
-rw-rw---- 1 guilhem  guilhem 2247446 Nov 12 16:47 gbichot2-bin.000005
-rw-rw---- 1 guilhem  guilhem  998412 Nov 14 10:08 gbichot2-bin.000006
-rw-rw---- 1 guilhem  guilhem     361 Nov 14 10:07 gbichot2-bin.index

再起動する度に、MySQL サーバは新たなバイナリ ログ ファイルを作成します。これには連続する番号のシーケンスがあります。サーバを実行する一方で、そのサーバに使用中のバイナリ ログ ファイルを閉じて、新しいファイルを開始するように命令することができます。それには手動で、FLUSH LOGS SQL ステートメント、または mysqladmin flush-logs コマンドを使用します。mysqldump にもログをフラッシュするオプションがあります。ディレクトリの MySQL バイナリ ログのすべてのリストを含む .index というファイルがデータ ディレクトリにあります。このファイルはレプリケーションに使用します。

MySQL バイナリ ログでは、インクリメント バックアップのセットを形成しているため、リカバリでは重要になります。フル バックアップを行う場合に、ログのフラッシュを確実に行うと、それ以後のバイナリ ログ ファイルは変更した部分だけのデータを含むファイルになります。ここで、前述の mysqldump コマンドを若干修正すると、フル バックアップを行った時点でのMySQL バイナリ ログをフラッシュするようになります。つまり、ダンプ ファイルには新しいバイナリ ログの名前を含むようになります。

shell> mysqldump --single-transaction --flush-logs --master-data=2 \
         --all-databases > backup_sunday_1_PM.sql

このコマンドを実行後、データ ディレクトリには gbichot2-bin.000007 という新しいバイナリ ログ ファイルができます。.sql ファイルは次のラインが入ります。

-- Position to start replication or point-in-time recovery from
-- CHANGE MASTER TO MASTER_LOG_FILE='gbichot2-bin.000007',»
                    MASTER_LOG_POS=4;

mysqldump コマンドでフル バックアップを取っているため、これらのラインは 2 つの意味があります。

そして、月曜の午後 1 時に、新しいバイナリ ログ ファイルでログを開始するために、それまでのログをフラッシュして、インクリメント バックアップを取ります。たとえば、mysqladmin flush-logs コマンドを実行して、gbichot2-bin.000008 というファイルを作成します。ここで、日曜の午後 1 時のフル バックアップを起点とし、月曜の午後 1 時までを終点とするすべての変更が、gbichot2-bin.000007 ファイルとなります。ここの手順で、このファイルには大事な役割があるので、コピーしてテープ、DVD、別のマシンなど安全な場所に保管しておきます。そして、翌日、火曜日の午後 1 時に、改めて、mysqladmin flush-logs コマンドを実行すると、gbichot2-bin.000008 ファイルが、月曜の午後 1 時を起点とし、火曜の午後 1 時を終点とするすべての変更を含むことになります。(これも安全な場所にコピーを保管します。)

MySQL バイナリ ログはディクス スペースを消費するので、必要に応じてスペースの解放が必要です。その 1 つの方法としては、たとえば、フル バックアップ後に不要なったバイナリ ログを削除します。

shell> mysqldump --single-transaction --flush-logs --master-data=2 \
         --all-databases --delete-master-logs > backup_sunday_1_PM.sql

注意：サーバがレプリケーションのマスタ サーバである場合は、mysqldump --delete-master-logs というコマンドで MySQL バイナリ ログを 削除するということには危険が伴います。つまり、スレーブ サーバでまだバイナリ ログの内容を完全に処理し切れていない可能性があります。PURGE MASTER LOGS ステートメントの詳細 (項12.6.1.1. 「PURGE MASTER LOGS 構文」) で、MySQL バイナリ ログを削除する前の確認操作について参照してください。