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

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

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

mysqldump によるバックアップの作成

mysqldump プログラムでバックアップを作成できます。 すべての種類のテーブルをバックアップできます。 (セクション7.4「バックアップへの mysqldump の使用」を参照してください。)

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

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

MyISAM テーブルは、テーブルファイル (*.MYD、*.MYI ファイルおよび関連する *.sdi ファイル) をコピーすることでバックアップできます。 一貫したバックアップを取得するには、サーバーを停止するか、関連するテーブルをロックしてフラッシュします。

FLUSH TABLES tbl_list WITH READ LOCK;

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

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

このバックアップ方法の例は、セクション13.2.5「IMPORT TABLE ステートメント」 のエクスポートおよびインポートの例を参照してください。

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

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

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

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

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

MySQL は、バイナリログを使用した増分バックアップをサポートしています。 バイナリログファイルは、バックアップを実行した時点のあとに行われたデータベースへの変更のレプリケートする必要がある情報を提供します。 したがって、サーバーを point-in-time にリストアできるようにするには、MySQL 8.0 のデフォルト設定であるバイナリロギングを有効にする必要があります ;セクション5.4.4「バイナリログ」 を参照してください。

増分バックアップ (最後の完全バックアップまたは増分バックアップ以降に発生したすべての変更を含む) を作成しようとするときは、FLUSH LOGS を使用して、バイナリログをローテーションしてください。 これが完了したら、最後の完全または増分バックアップの瞬間から最後の 1 つ前の範囲のすべてのバイナリログをバックアップの場所にコピーする必要があります。 これらのバイナリログは増分バックアップで、リストア時に、セクション7.5「Point-in-Time (増分) リカバリ」に説明するように、それらを適用します。 次回全体バックアップを実行するときは、FLUSH LOGS または mysqldump --flush-logs を使用してバイナリログもローテーションするようにしてください。 セクション4.5.4「mysqldump — データベースバックアッププログラム」を参照してください。

レプリカを使用したバックアップの作成

バックアップの作成中にサーバーでパフォーマンスの問題が発生した場合、レプリケーションを設定し、ソースではなくレプリカでバックアップを実行するという戦略が役立ちます。 セクション17.4.1「バックアップ用にレプリケーションを使用する」を参照してください。

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

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

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

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

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

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