Skip navigation links
4.5.2 BACKUP TABLE 構文 »
Section Navigation      [Toggle]

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

MySQL テーブルはファイルとして保存されるため、バックアップが簡単です。一貫したバックアップを行うには、そのテーブルに対して LOCK TABLES を実行してから、FLUSH TABLES を実行します。 See 項6.7.5. 「LOCK TABLES および UNLOCK TABLES 構文」。 See 項4.6.4. 「FLUSH 構文」。 読み取りロックだけが必要なので、データベースディレクトリのファイルをコピーしている間も、他のスレッドはテーブルに対してクエリを続行できます。FLUSH TABLE は、バックアップを開始する前に、キャッシュされているページをすべてディスクに書き込むために必要です。

3.23.56 から 4.0.12 では、セキュリティ上のリスクがあるため、BACKUP TABLE で既存ファイルの上書きはできないようになっています。

テーブルを SQL レベルでバックアップするには、SELECT INTO OUTFILE または BACKUP TABLE を使用します。 See 項6.4.1. 「SELECT 構文」。 See 項4.5.2. 「BACKUP TABLE 構文」。

データベースのバックアップには、mysqldump プログラムまたは mysqlhotcopy script を使用することもできます。 See 項4.9.7. 「mysqldump（テーブル構造とデータのダンプ）」。 See 項4.9.8. 「mysqlhotcopy（MySQL のデータベースとテーブルのコピー）」。

  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 テーブルと ISAM テーブルにのみ有効。

  2. mysqld が実行中であればいったん停止し、--log-bin[=file_name] オプションで再起動する。See 項4.10.4. 「バイナリログ」。 mysqldump 実行後に行われたデータの変更をレプリケートするための情報が、バイナリログファイルにより提供される。

MySQL サーバがスレーブの場合、どのバックアップ方法を選択しても、スレーブのデータをバックアップするとき、master.info ファイルと relay-log.info ファイルもバックアップしてください。これらのファイルは、スレーブのデータをリストア後、レプリケーションを再開するときに必要です。スレーブが、レプリケーションを行う LOAD DATA INFILE コマンドの対象となっていた場合、SQL_LOAD-* ファイルもバックアップしてください。このファイルは、--slave-load-tmpdir オプションによって指定されているディレクトリにあります（このファイルの場所が指定されていない場合、デフォルトで、この場所は tmpdir 変数の値になります）。中断されていた LOAD DATA INFILE 処理のレプリケーションを再開するためにスレーブはこれらのファイルを必要とします。

何かをリストアする必要がある場合、最初に REPAIR TABLE または myisamchk -r を使用してテーブルのリカバリを試みてください。ほとんどの場合、これで成功するはずです。myisamchk でリカバリできなかった場合、以下を実行します。これは、--log-bin で MySQL を起動している場合にのみ可能な方法です。項4.10.4. 「バイナリログ」 を参照してください。

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

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

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

    場合に応じて、特定の位置から後のバイナリログだけを再実行する（通常は、リストアしたバックアップの日付以降の、不正なクエリ以外のすべてのバイナリログを再実行する）。 mysqlbinlog ユーティリティおよびその使用法の詳細については、項4.9.5. 「mysqlbinlog（バイナリログからクエリを実行する）」 を参照のこと。

    更新ログ（MySQL 5.0 で廃止）を使用している場合、更新ログの内容を以下のように実行できる。 

    shell> ls -1 -t -r hostname.[0-9]* | xargs cat | mysql

    ls は、すべての更新ログファイルを正しい順序で取得するために使用します。

SELECT * INTO OUTFILE 'file_name' FROM tbl_name で選択的バックアップを行い、LOAD DATA INFILE 'file_name' REPLACE ... でリストアすることもできます。重複テーブルを避けるため、テーブルに PRIMARY KEY または UNIQUE キーが必要です。REPLACE キーワードを使用すると、ユニークキーが新規レコードと旧レコードで重複していた場合に、旧レコードが新規レコードで置き換えられます。

バックアップに伴いパフォーマンス上の問題が発生する場合、レプリケーションをセットアップして、マスタではなくスレーブ上でバックアップを実行することによりこの問題を解決できる。 See 項4.11.1. 「はじめに」。

Veritas ファイルシステムを使用している場合、以下を実行できます。

  1. クライアント（または Perl）から、FLUSH TABLES WITH READ LOCK を実行する。

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

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

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

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

This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.