Skip navigation links
4.9.2 バックアップとリカバリ手法の例示 »
Section Navigation      [Toggle]

4.9.1. データベースのバックアップ

MySQL テーブルはファイルとして保存するため、バックアップを簡単に行えます。整合性のあるバックアップを行うには、関連するテーブルで LOCK TABLES を行い、そのテーブルを FLUSH TABLES します。(項12.4.5. 「LOCK TABLES と UNLOCK TABLES 構文」 と 項12.5.5.2. 「FLUSH 構文」 を参照のこと。) 読み込みロックだけを行うため、データベース ディレクトリのファイル コピーを行う一方で、別のクライアントはテーブル照会を続けることができます。ここで、FLUSH TABLES ステートメントを必要とする理由は、バックアップを開始する前に、アクティブのインデックス ページすべてのディスクへの書き込みを確実に行うためです。

テーブルを SQL レベルでバックアップするには、SELECT INTO ... OUTFILE を使用します。ファイルの上書きはセキュリティ リスクに繋がるため、このステートメントでは既存のファイル名を指定する事は出来ません。項12.2.7. 「SELECT 構文」 を参照してください。

データベースをバックアップする別のテクニックとして、mysqldump または mysqlhotcopy script を使用する方法があります。項7.12. 「mysqldump — データベースバックアッププログラム」、項7.13. 「mysqlhotcopy — データベースバックアッププログラム」 をそれぞれ参照してください。

  1. データベースのフル バックアップ方法 

    shell> mysqldump --tab=/path/to/some/dir --opt db_name

    または 

    shell> mysqlhotcopy db_name /path/to/some/dir

    サーバが更新作業中でなければ、バイナリ バックアップを *.frm、*.MYD、*.MYI などのテーブル ファイルをコピーする方法もある。そのときは、mysqlhotcopy スクリプト を使用する。ただし、データベースに InnoDB テーブルがある場合には、この方法でバックアップすることはできない。InnoDB にはデータベース ディレクトリにテーブル内容を保存していないため、mysqlhotcopy は、MyISAM テーブルの場合にだけ使用する。

  2. mysqld を実行している場合は、終了して、--log-bin[=file_name] オプションでこれを立ち上げる。(項4.11.4. 「バイナリ ログ」 を参照のこと。) バイナリ ログ ファイルには、mysqldump を実行したその時点から後のデータ変更を複製するときに必要な情報が入っている。

InnoDB テーブルに対して、オンライン バックアップはできますが、テーブルにはロックがありません。項7.12. 「mysqldump — データベースバックアッププログラム」 を参照のこと。

MySQL の増加分バックアップ (インクリメント)： バイナリ ロギングができるようにするために、サーバを --log-bin オプションで起動します。(項4.11.4. 「バイナリ ログ」 を参照のこと。) インクリメント バックアップを行う時点で、FLUSH LOGS を使用して、バイナリ ログをローテートします。 (このときのバックアップ内容とは、前回のフルまたはインクリメント バックアップをしてから発生した変更のことです。) ローテートを行った後、バックアップする部分をコピーします。この部分の範囲は、前回のバックアップ (フルまたはインクリメント) を行た時点を起点とし、このバックアップ操作を行う時点までを終点とします。つまり、追加部分です。(インクリメント バックアップには、リストアした時点でのバイナリ ログが 2 つあるということで、これは順次説明します。つまり、次回、フル バックアップを行うときも、FLUSH LOGS、mysqldump --flush-logs、mysqlhotcopy --flushlog のいずれかを使用してバイナリ ログのローテートが必要です。詳細は、項7.12. 「mysqldump — データベースバックアッププログラム」 と 項7.13. 「mysqlhotcopy — データベースバックアッププログラム」 を参照のこと。)

MySQL サーバがレプリケーション スレーブである場合、どのようなバックアップの方法を取るとしても、スレーブのデータをバックアップするときには、master.info と relay-log.info の両ファイルをバックアップしてください。これらのファイルは、スレーブのデータをリストアするときに、レプリケーションのレジューム (再開) に必要です。スレーブが LOAD DATA INFILE コマンドを使用するレプリケーションの対象である場合、ディレクトリの SQL_LOAD-* ファイルもバックアップしてください。このファイルは、--slave-load-tmpdir オプションを指定すると出てきます。(このファイル位置を指定しない場合、この位置は tmpdir 変数の値 (デフォルト) になります。) このファイルは、LOAD DATA INFILE 操作が中断した場合などに、スレーブのレプリケーション再開で必要になります。

MyISAM テーブルをリストアする必要がある場合、まず REPAIR TABLE または myisamchk -r を使用して、リカバリしてください。この方法は、99.9% 確実です。myisamchk コマンドで失敗した場合は、次の手順を試行します。ノート： この方法は、MySQL を --log-bin オプションで立ち上げ、バイナリ ロギングを行っていた場合にだけ通用します。

  1. オリジナルの mysqldump バックアップ、またはバイナリ バックアップをリストアする。

  2. 次のコマンドを実行し、バイナリ ログの更新を再実行する。 

    shell> mysqlbinlog binlog.[0-9]* | mysql

    場合によっては、特定の場所からのバイナリ ログだけを再実行する必要がある。通常は、バイナリ ログのすべてを再実行にはリストアしたバックアップの日から行うが、これには適切ではないステートメントが含まれている場合がある。項7.10. 「mysqlbinlog — バイナリログファイルを処理するためのユーティリティ」 で、mysqlbinlog ユーティリティとその使用に関する詳細を参照のこと。

個別ファイルの部分的なバックアップを行う場合：

  • テーブルをダンプするには、SELECT * INTO OUTFILE 'file_name' FROM tbl_name を使用する。

  • テーブルをリロードするには、LOAD DATA INFILE 'file_name' REPLACE ... を使用する。テーブルに PRIMARY KEY または UNIQUE インデックスがあれば、レコードの重複を避けることができる。一意のキー値がある場合、REPLACE キーワードは、古いレコードが新しいものと入え替るので注意が必要。

バックアップするときにサーバにパフォーマンス上の問題が発生する場合、レプリケーションをセットアップして、マスタではなくスレーブ上でバックアップを実行することによりこの問題を解決できます。章 5. レプリケーション を参照のこと。

Veritas ファイルシステムを使用している場合、次の手順でバックアップを行います。

  1. クライアント プログラムから、FLUSH TABLES WITH READ LOCK を実行する。

  2. 別のシェルから、mount vxfs snapshot を実行する。

  3. 最初のクライアントから、UNLOCK TABLES を実行する。

  4. スナップショットからファイルをコピーする。

  5. スナップショットのマウントを解除する。