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


MySQL 5.6 リファレンスマニュアル  /  バックアップとリカバリ  /  データベースバックアップ方法

7.2 データベースバックアップ方法

このセクションでは、バックアップを作成する場合の一般的な方法をまとめています。

MySQL Enterprise Backup によるホットバックアップの作成

MySQL Enterprise Edition のお客様は MySQL Enterprise Backup 製品を使用して、インスタンス全体または選択されたデータベース、テーブル、またはその両方の物理バックアップを実行できます。この製品には、増分および圧縮バックアップの機能が含まれます。物理データベースファイルのバックアップは、リストアが mysqldump コマンドなどの論理技法よりはるかに高速になります。InnoDB テーブルはホットバックアップメカニズムを使用してコピーされます。(理想的には InnoDB テーブルでデータの大部分を表しているべきです。)ほかのストレージエンジンのテーブルは、ウォームバックアップメカニズムを使用してコピーされます。MySQL Enterprise Backup 製品の概要については、セクション25.2「MySQL Enterprise Backup」を参照してください。

mysqldump または mysqlhotcopy によるバックアップの作成

mysqldump プログラムと mysqlhotcopy スクリプトでバックアップを作成できます。mysqldump はあらゆる種類のテーブルをバックアップできるため、より汎用的です。mysqlhotcopy は一部のストレージエンジンでのみ機能します。(セクション7.4「バックアップへの mysqldump の使用」およびセクション4.6.10「mysqlhotcopy — データベースバックアッププログラム」を参照してください。)

InnoDB テーブルの場合、mysqldump--single-transaction オプションを使用して、テーブルをロックしないオンラインバックアップを実行できます。セクション7.3.1「バックアップポリシーの確立」を参照してください。

テーブルファイルのコピーによるバックアップの作成

独自のファイルを使用して、各テーブルを表すストレージエンジンの場合、テーブルはそれらのファイルをコピーしてバックアップできます。たとえば、MyISAM テーブルはファイルとして格納されるため、ファイル (*.frm*.MYD、および *.MYI ファイル) をコピーして、簡単にバックアップを行うことができます。一貫したバックアップを取得するには、サーバーを停止するか、関連するテーブルをロックしてフラッシュします。

FLUSH TABLES tbl_list WITH READ LOCK;

読み取りロックのみが必要です。これにより、データベースディレクトリ内のファイルのコピー中に、ほかのクライアントが引き続きテーブルをクエリーすることができます。バックアップを開始する前に、すべてのアクティブインデックスページがディスクに書き込まれるようにするため、フラッシュが必要です。セクション13.3.5「LOCK TABLES および UNLOCK TABLES 構文」およびセクション13.7.6.3「FLUSH 構文」を参照してください。

サーバーが何も更新していないかぎり、すべてのテーブルファイルをコピーすることによって、バイナリバックアップを簡単に作成することもできます。mysqlhotcopy スクリプトはこの方法を使用します。(ただし、テーブルファイルコピー方法は、データベースに InnoDB テーブルが含まれている場合、機能しません。InnoDB では必ずしもデータベースディレクトリにテーブルの内容を格納しないため、mysqlhotcopyInnoDB テーブルで機能しません。さらに、サーバーがアクティブにデータを更新していない場合、InnoDB は変更されたデータをまだメモリー内にキャッシュしており、ディスクにフラッシュしていないことがあります。)

区切りテキストファイルバックアップの作成

テーブルのデータを含むテキストファイルを作成するには、SELECT * INTO OUTFILE 'file_name' FROM tbl_name を使用できます。このファイルはクライアントホストではなく、MySQL サーバーホスト上に作成されます。このステートメントの場合、ファイルの上書きを許可すると、セキュリティーリスクになるため、出力ファイルがすでに存在していてはなりません。セクション13.2.9「SELECT 構文」を参照してください。この方法はあらゆる種類のデータファイルに機能しますが、テーブルデータのみ保存し、テーブル構造は保存しません。

テキストデータファイル (バックアップされたテーブルの CREATE TABLE ステートメントを含むファイルに加えて) を作成する別の方法は、mysqldump--tab オプションを使用することです。セクション7.4.3「mysqldump による区切りテキストフォーマットでのデータのダンプ」を参照してください。

区切りテキストデータファイルをリロードするには、LOAD DATA INFILE または mysqlimport を使用します。

バイナリログを有効にすることによる増分バックアップの作成

MySQL は増分バックアップをサポートします。--log-bin オプションでサーバーを起動し、バイナリロギングを有効にする必要があります。セクション5.2.4「バイナリログ」を参照してください。バイナリログファイルは、バックアップを実行した時点のあとに行われたデータベースへの変更のレプリケートする必要がある情報を提供します。増分バックアップ (最後の完全バックアップまたは増分バックアップ以降に発生したすべての変更を含む) を作成しようとするときは、FLUSH LOGS を使用して、バイナリログをローテーションしてください。これが完了したら、最後の完全または増分バックアップの瞬間から最後の 1 つ前の範囲のすべてのバイナリログをバックアップの場所にコピーする必要があります。これらのバイナリログは増分バックアップで、リストア時に、セクション7.5「バイナリログを使用したポイントインタイム (増分) リカバリ」に説明するように、それらを適用します。次回に完全バックアップを行うときも、FLUSH LOGSmysqldump --flush-logs、または mysqlhotcopy --flushlog を使用してバイナリログをローテーションしてください。セクション4.5.4「mysqldump — データベースバックアッププログラム」およびセクション4.6.10「mysqlhotcopy — データベースバックアッププログラム」を参照してください。

レプリケーションスレーブを使用したバックアップの作成

バックアップの作成中に、マスターサーバーにパフォーマンスの問題がある場合、役に立つ可能性のある 1 つの戦略は、マスターではなくスレーブでレプリケーションをセットアップし、バックアップを実行することです。セクション17.3.1「バックアップ用にレプリケーションを使用する」を参照してください。

スレーブレプリケーションサーバーをバックアップする場合、選択したバックアップ方法に関係なく、スレーブのデータベースをバックアップする際に、そのマスター情報とリレーログ情報のリポジトリをバックアップしてください (セクション17.2.2「レプリケーションリレーおよびステータスログ」を参照してください)。これらの情報ファイルは、スレーブのデータをリストアしたあとに、レプリケーションを再開するために常に必要です。スレーブが LOAD DATA INFILE ステートメントをレプリケートする場合、スレーブがこのために使用するディレクトリ内に存在する SQL_LOAD-* ファイルもバックアップしてください。スレーブは、中断した LOAD DATA INFILE 操作のレプリケーションを再開するためにこれらのファイルを必要とします。このディレクトリの場所は --slave-load-tmpdir オプションの値です。そのオプションでサーバーを起動しなかった場合、ディレクトリの場所は tmpdir システム変数の値になります。

破損したテーブルのリカバリ

破損した MyISAM テーブルをリストアする必要がある場合、まず REPAIR TABLE または myisamchk -r を使用して、それらのリカバリを試みます。それは、すべてのケースの 99.9% で機能するはずです。myisamchk が失敗した場合は、セクション7.6「MyISAM テーブルの保守とクラッシュリカバリ」を参照してください。

ファイルシステムスナップショットを使用したバックアップの作成

Veritas ファイルシステムを使用している場合、次のようにバックアップを作成できます。

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

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

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

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

  5. スナップショットをアンマウントします。

同様のスナップショット機能は、LVM や ZFS などのほかのファイルシステムでも利用できます。


User Comments
  Posted by jeroen playak on November 29, 2009
I wrote a PHP script that creates gzipped backups (one per table), so you'll always have all tables backed up, without having to backup tables that haven't changed. Details and download: http://www.netpresent.net/index.php/products-topmenu-3#mysqlincbak . Especially handy if you're uploading the backup files to a service like Amazon S3 with duplicity or similar.

  Posted by Vlatko Šurlan on July 4, 2010
There is an interesting script sample here: http://www.docplanet.org/linux/backing-up-linux-web-server-live-via-ssh/
showing a way to dump mysql databases directly into gzip and then into ssh connection, thus creating a tarball archive that never resided on the server hard drive. This can be a handy way to ensure that backup does not fill up the server hard drive and can help you backup your server even when it is near 100% full.
  Posted by Lloyd Standish on July 17, 2010
FLUSH TABLES WITH READ LOCK is extremely convenient for making a full backup of all MyISAM databases. However, the database locks are released as soon as the mysql session ends, which is why this backup-methods page suggests that FLUSH TABLES WITH READ LOCK be executed in one shell, while the backup command is run from a separate shell.

Unfortunately, this won't work when the backup is executed from a shell script, such as during scheduled backups via cron.

To hold the lock on all databases while running an automated backup script, the mysql SYSTEM command can be used to execute a backup script before the mysql session ends, like this:

echo "FLUSH TABLES WITH READ LOCK; SYSTEM /path/to/helper/backupscript.sh; UNLOCK TABLES;" | mysql -u <user> -p <password>

The file /path/to/helper/backupscript.sh would have the actual backup command. For example, I have:

rsync -vza --delete /var/lib/mysql root@backup.my_server.com:/root/rimubackups/ | tee /root/crontasks/mysqlbackup.log

  Posted by Dan W on January 19, 2011
A modification of Lloyd's example is to use a snapshot filesystem so that the database doesn't have to be offline for an extended period of time. This way the database is offline for a few seconds at most. ie:

echo "FLUSH TABLES WITH READ LOCK; SYSTEM /path/to/helper/snap-start.sh; UNLOCK TABLES;" | mysql -u <user> -p <password>
rsync -arv /snapshot/var/lib/mysql /path/to/backupstorage/
/path/to/helper/snap-stop.sh

The file /path/to/helper/snap-start.sh would have the commands to create the snapshot partition:

/usr/sbin/lvcreate --size 28G --snapshot --name snap /dev/VolGroup00/LogVol00
mount /dev/VolGroup00/snap /snapshot

The file /path/to/helper/snap-stop.sh would have the commands to remove the snapshot partition:

umount /snapshot
/usr/sbin/lvremove /dev/VolGroup00/snap

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