1.4 バックアップされるファイル

DBA と開発作業には通常、テーブル、行、カラム、データディクショナリなどの論理構造が含まれます。バックアップでは、これらの構造がファイルによってどのように表されているかに関する物理的な詳細を理解しておく必要があります。

表 1.1 MySQL Enterprise Backup 出力ディレクトリ内のファイル

ファイル名、パターン、または拡張子	元のデータファイルとの関係	注
ibdata*	InnoDB システムテーブルスペース。複数の InnoDB テーブルおよび関連したインデックスが含まれます。	バックアップの進行中に元のファイルが変更される可能性があるため、apply-log ステップで、対応するバックアップファイルに同じ変更内容が適用されます。
*.ibd	InnoDB file-per-table テーブルスペース。それぞれに単一の InnoDB テーブルおよび関連したインデックスが含まれます。	innodb_file_per_table 下で作成されたテーブルに使用されます。バックアップの進行中に元のファイルが変更される可能性があるため、apply-log ステップで、対応するバックアップファイルに同じ変更内容が適用されます。
*.ibz	MySQL データディレクトリからの InnoDB データファイルの圧縮された形式。	圧縮バックアップで .ibd ファイルの代わりに生成されます。InnoDB システムテーブルスペースを表す ibdata* ファイルも、圧縮バックアップではこの拡張子になります。 .ibz ファイルは、apply-log ステップのために圧縮解除されます。
*.frm	すべての MySQL テーブルに関するメタデータを保持します。	これらのファイルがコピーされている間、データベースは読み取り専用状態になります。これらのファイルは変更なしにコピーされます。
*.MYD	MyISAM テーブルデータ。	これらのファイルがコピーされている間、データベースは読み取り専用状態になります。これらのファイルは変更なしにコピーされます。
*.MYI	MyISAM インデックスデータ。	これらのファイルがコピーされている間、データベースは読み取り専用状態になります。これらのファイルは変更なしにコピーされます。
*.CSM	CSV テーブルのメタデータ。	これらのファイルは変更なしにコピーされます。mysqlbackup で作成される backup_history テーブルと backup_progress テーブルでは CSV 形式が使用されるため、バックアップには常にこの拡張子のファイルが含まれます。
*.CSV	CSV テーブルのデータ。	これらのファイルは変更なしにコピーされます。mysqlbackup で作成される backup_history テーブルと backup_progress テーブルでは CSV 形式が使用されるため、バックアップには常にこの拡張子のファイルが含まれます。
*.MRG	MERGE ストレージエンジンはほかのテーブルを参照します。	これらのファイルがコピーされている間、データベースは読み取り専用状態になります。これらのファイルは変更なしにコピーされます。
*.TRG	トリガーパラメータ。	これらのファイルがコピーされている間、データベースは読み取り専用状態になります。これらのファイルは変更なしにコピーされます。
*.TRN	トリガー名前空間情報。	これらのファイルがコピーされている間、データベースは読み取り専用状態になります。これらのファイルは変更なしにコピーされます。
*.opt	データベース構成情報。	これらのファイルがコピーされている間、データベースは読み取り専用状態になります。これらのファイルは変更なしにコピーされます。
*.par	パーティション化されたテーブルの定義。	これらのファイルがコピーされている間、データベースは読み取り専用状態になります。これらのファイルは変更なしにコピーされます。
*.ARM	アーカイブストレージエンジンメタデータ。	これらのファイルがコピーされている間、データベースは読み取り専用状態になります。これらのファイルは変更なしにコピーされます。
*.ARZ	アーカイブストレージエンジンデータ。	これらのファイルがコピーされている間、データベースは読み取り専用状態になります。これらのファイルは変更なしにコピーされます。
backup-my.cnf	MySQL データファイルのレイアウトを指定する構成パラメータを記録します。	リストア操作で、バックアップが作成された時点と同じレイアウトを再生成するために使用されます。
ibbackup_logfile	MySQL データディレクトリからの ib_logfile* ファイルの短縮バージョン。	InnoDB ログファイル (ib_logfile*) は、データベース操作中に継続的に更新される固定サイズのファイルです。バックアップの目的では、バックアップが進行している間にコミットされた変更内容だけが必要になります。これらの変更内容は、ibbackup_logfile に記録され、apply-log フェーズ中に ib_logfile* ファイルの再作成に使用されます。
ibbackup_redo_log_only	--incremental-with-redo-log-only オプションを使用して行われる増分バックアップで、ibbackup_logfile の代わりに使用されます。
ib_logfile*	最初のバックアップ後、apply-log フェーズ中にバックアップディレクトリに作成されます。	これらのファイルは元のデータディレクトリからコピーされるのではなく、ibbackup_logfile ファイルに記録された変更内容を使用して、最初のバックアップ後、apply-log フェーズ中にバックアップディレクトリに再作成されます。
*.bl	バックアップ対象サーバーからの各 .isl ファイルの名前を変更したバージョン。	CREATE TABLE ... DATA DIRECTORY = ... の構文を使用して InnoDB テーブルの場所を指定するときに、.isl ファイルは作成され、テーブルスペースファイルを指し示すシンボリックリンクのように機能します。(詳細は テーブルスペースの位置の指定を参照してください。).bl ファイルは、copy-back 操作中に .isl ファイルに戻される場合も戻されない場合もあります。バックアップがリストアされるサーバーに、指定されたディレクトリが存在しない場合、mysqlbackup コマンドはこのディレクトリを作成しようと試みます。ディレクトリを作成できない場合、リストア操作は失敗します。したがって、DATA DIRECTORY 句を使用してテーブルを異なる場所に配置し、対応するディレクトリを作成できずファイル構造が異なるサーバーにリストアする場合は、リストアする前に、リストア先のサーバー上に存在するディレクトリを指し示すように .bl ファイルを編集してください。
2011-05-26_13-42-02 などのタイムスタンプが記されたディレクトリ	--with-timestamp オプションで作成されます。すべてのバックアップファイルはこのサブディレクトリ内に保存されます。	複数セットのバックアップデータを同一の主要なバックアップディレクトリ下で継続的に利用する場合は必ず、--with-timestamp オプションを使用してください。
datadir ディレクトリ	元の MySQL インスタンスからのすべてのデータファイルとデータベースサブディレクトリを格納するサブディレクトリ。	mysqlbackup コマンドによって、バックアップディレクトリ下に作成されます。
バイナリログファイル	サーバーからのバイナリログファイル。これらはデフォルトでバックアップに含められます。これらにより、サーバーのスナップショットを取得できるため、サーバーを正確にクローン化できます。完全バックアップを基本として使用しながら、増分バックアップに含まれるバイナリログファイルは、前回の完全バックアップ以降の特定の時点の状態にデータベースをリストアするポイントインタイム・リカバリ (PITR) に使用できます。詳細は、セクション4.3「ホットバックアップからのポイントインタイム・リカバリ」を参照してください。	バックアップディレクトリ下の datadir ディレクトリの下に保存されます。--skip-binlog オプションを使用して、バックアップでバイナリログを除外します。MySQL 5.5 の場合はすべてのオフラインバックアップと同様に、mysqlbackup がバイナリログファイルを見つけてバックアップに含めることができるように、--log-bin-index オプションを使用して、使用中のすべてのバイナリログファイルを一覧表示した、MySQL サーバー上のインデックスファイルの絶対パスを指定してください (オプションのデフォルト値と異なる場合)。 注記 一部の既知の問題のため、オフラインバックアップを作成するときや、--no-locking オプションで作成された完全バックアップに基づいた増分バックアップを作成するときには、ユーザーは常に --skip-binlog オプションを使用する必要があります。詳細は、付録A「MySQL Enterprise Backup の制限」を参照してください。
リレーログファイル	スレーブサーバーからのリレーログファイル。これらは、デフォルトでスレーブサーバーのバックアップに含められます。これらが含まれているため、スレーブがリストアされているときに、マスターからリレーログを取り出すために必要な時間とリソースが節約されます。	バックアップディレクトリ下の datadir ディレクトリの下に保存されます。バックアップでリレーログを除外するには、--skip-relaylog オプションを使用してください。オフラインバックアップの場合、mysqlbackup がリレーログファイルを見つけてバックアップに含めることができるように、--relay-log-index オプションを使用して、使用中のすべてのリレーログファイルを一覧表示した、MySQL サーバー上のインデックスファイルの絶対パスを指定してください (オプションのデフォルト値と異なる場合)。
スレーブステータスログファイル	通常、これらのファイルは master.info および relay-log.info という名前が付けられ、デフォルトで、レプリケーションを行うときにスレーブデータベースのバックアップに含められます。詳細は、スレーブステータスログを参照してください。	バックアップディレクトリ下の datadir ディレクトリの下に保存されます。オフラインバックアップの場合、mysqlbackup がこれらのファイルを見つけてバックアップに含めることができるように、--master-info-file オプションと --relaylog-info-file オプションを使用して、情報ファイルの絶対パスを指定してください (オプションのデフォルト値と異なる場合)。
画像ファイル	--backup-image オプションで指定された名前が付けられた、backup-to-image オプションによって生成された単一ファイルのバックアップ。	バックアップデータディレクトリがゼロバイトのファイルのみで構成され、最上位のディレクトリに単一の巨大なデータファイルがある場合は、単一ファイルのバックアップが存在しています。内部のコンテンツを損失または損傷することなくイメージファイルを移動し、続いて extract オプションを使用し、--backup-image オプションで同じイメージ名を指定した mysqlbackup コマンドでそのファイルをアンパックします。backup-my.cnf などの一部の付加的なファイルと meta サブディレクトリはバックアップディレクトリに存在しますが、これらのファイルはイメージファイルにも含められ、一緒に移動する必要はありません。
ほかのすべてのファイル	MySQL データディレクトリからコピーされます。	デフォルトで、MySQL データディレクトリ内の認識されないファイルはすべて、バックアップにコピーされます。このようなファイルを除外するには、--only-known-file-types オプションを指定してください。
meta ディレクトリ	バックアップに関するメタデータを含むファイルを格納したサブディレクトリ。	mysqlbackup コマンドによって、バックアップディレクトリ下に作成されます。次に一覧表示されたすべてのファイルは、meta サブディレクトリ内に置かれます。
backup_variables.txt	バックアップに関する重要な情報が保持されます。mysqlbackup コマンド専用です。MySQL Enterprise Backup 3.6 以前では、この情報は ibbackup_binlog_info という名前のファイルに含まれていました。	mysqlbackup コマンドは、apply-log フェーズや restore フェーズなど、最初のバックアップ後の操作中にこのファイルを参照し、多くの場合更新します。
image_files.xml	backup-to-image オプションまたは backup-dir-to-image オプションで生成された単一ファイルのバックアップに存在するすべてのファイル (それ自身を除く) のリストが含まれます。このファイルの詳細は、セクション10.5「MySQL Enterprise Backup マニフェストの使用」を参照してください。	このファイルはいったん生成されると、どの段階でも変更されません。
backup_create.xml	コマンド行引数と、バックアップが作成された環境を一覧表示します。このファイルの詳細は、セクション10.5「MySQL Enterprise Backup マニフェストの使用」を参照してください。	このファイルはいったん作成されると、変更されません。--disable-manifest オプションを指定することによって、このファイルが生成されないようにすることができます。
backup_content.xml	バックアップデータのファイルおよびデータベース定義の基本メタデータ。バックアップ対象サーバー上で定義されているすべてのプラグインの詳細も含まれます。ユーザーはこの詳細から、同じプラグインがリストアのターゲットサーバー上でも同じように定義されていることを確認する必要があります。このファイルの詳細は、セクション10.5「MySQL Enterprise Backup マニフェストの使用」を参照してください。	このファイルはいったん作成されると、変更されません。--disable-manifest オプションを指定することによって、このファイルが生成されないようにすることができます。
comments.txt	--comments オプションまたは --comments-file オプションによって生成されます。	コメントは、このバックアップジョブの目的または特別な考慮事項について記すためにユーザーが指定します。
gtid_executed.sql	GTID を有効にしたサーバーから取得されたバックアップを指定します。	GTID は、MySQL 5.6 以上のレプリケーション機能です。詳細は、グローバルトランザクション識別子を使用したレプリケーションを参照してください。GTID を有効にしたサーバーをバックアップすると、バックアップディレクトリに gtid_executed.sql のファイルが作成されます。スレーブサーバー上にバックアップデータをリストアしたあとで、このファイルを編集し実行します。
server-my.cnf	デフォルト以外の値に設定された、バックアップ対象サーバーのグローバル変数の値が含まれます。このファイルまたは server-all.cnf を使用して、リストアのターゲットサーバーを起動します。	copy-back または copy-back-and-apply-log 操作中、ファイル内のサーバーリポジトリオプションの値 (--datadir、--innodb_data_home_dir など) は、コマンドオプションを通じてコマンドによって変更がなされた場合に変更されます。ただし、--apply-incremental-backup 操作中は、ファイルにすでに保存された値が優先され、コマンドを通じて与えられるオプション値によって変更されません。 警告 ファイルを使用してターゲットサーバーを再起動するときには、ターゲットサーバーが誤って間違ったファイルの場所を使用しないようにするために、--tmpdir、--general-log などのパラメータと、絶対ファイルパスを使用するすべてのグローバル変数を変更してください。
server-all.cnf	バックアップ対象サーバーのすべてのグローバル変数の値が含まれます。このファイルまたは server-my.cnf を使用して、リストアのターゲットサーバーを起動します。	copy-back または copy-back-and-apply-log 操作中、ファイル内のサーバーリポジトリオプションの値 (--datadir、--innodb_data_home_dir など) は、コマンドオプションを通じてコマンドによって変更がなされた場合に変更されます。ただし、--apply-incremental-backup 操作中は、ファイルにすでに保存された値が優先され、コマンドを通じて与えられるオプション値によって変更されません。 警告 ファイルを使用してターゲットサーバーを再起動するときには、ターゲットサーバーが誤って間違ったファイルの場所を使用しないようにするために、--tmpdir、--general-log などのパラメータと、絶対ファイルパスを使用するすべてのグローバル変数を変更してください。

InnoDB データ

InnoDB ストレージエンジンで管理されるデータは常にバックアップされます。バックアップされる主な InnoDB 関連データには、システムテーブルスペースとおそらくはいくつかのユーザーテーブルのデータを表す ibdata* ファイル、file-per-table 設定を有効にして作成されたユーザーテーブルからのデータを含む .ibd ファイル、新しいバックアップファイル ibbackup_logfile に格納される ib_logfile* ファイル (バックアップの実行中に行われた変更内容を表す再実行ログ情報) から抽出されたデータなどがあります。

圧縮バックアップ機能を使用する場合、.ibd ファイルは、圧縮形式で .ibz ファイル に名前が変更されます。

これらのファイルは、最初にコピーされるときに、リストアする準備が整うまでにさらなる処理を必要とする raw バックアップを形成します。続いて、適用ステップを実行すると、ibbackup_logfile ファイルに記録された変更内容に基づいてバックアップファイルが更新され、準備されたバックアップが作成されます。この時点で、バックアップデータは単一時点に対応します。ファイルはこれで、元の場所にリストアしたり、テスト、レポート、配備などのほかのいくつかの用途のためにレプリケーションスレーブとしてリストアしたりする準備ができました。

InnoDB テーブルを元の状態にリストアするには、バックアップデータとともに対応する .frm ファイルも必要です。このファイルがないと、バックアップ以後にだれかが ALTER TABLE または DROP TABLE ステートメントを実行した場合には、テーブル定義が欠落または失効する可能性があります。デフォルトでは、mysqlbackup コマンドは自動的に .frm ファイルをバックアップ操作中にコピーし、リストア操作中にファイルをリストアします。

MyISAM およびほかのストレージエンジンからのデータ

mysqlbackup コマンドは、MyISAM テーブルの .MYD ファイル、.MYI ファイル、および関連した .frm ファイルもバックアップできます。このリストに示されているように、同じことがほかの拡張子のファイルにも適用されます。

注記

MySQL Enterprise Backup では InnoDB 以外のデータ (MYISAM テーブルなど) をバックアップできますが、バックアップする MySQL サーバーで InnoDB をサポートしている必要があり (つまり、サーバーが --innodb=OFF または --skip-innodb オプションを使用して起動された場合、バックアッププロセスは失敗します)、サーバーに少なくとも 1 つの InnoDB テーブルが含まれている必要があります。

MyISAM テーブルとこれらのほかのタイプのファイルは、InnoDB テーブルで可能な同じ非ブロック方法では、バックアップすることはできません。このフェーズは、ウォームバックアップです。これらのテーブルがバックアップされている間は、おそらくはしばらくデータベースが応答しないようにして、これらのテーブルへの変更は妨げられますが、バックアップ中のシャットダウンは不要です。

注記

処理が集中したデータベースのバックアップ中に起こる同時実行の問題を回避するために、--only-innodb オプションまたは --only-innodb-with-frm オプションを使用して、InnoDB テーブルと関連データだけをバックアップできます。

バックアップに含まれる生成されたファイル

バックアップデータには、バックアッププロセス中に生成された新しいファイルが含まれます。これらのファイルは、バックアップデータの検証やリストアなど、後から行うタスクを制御するために使用されます。バックアッププロセス中に生成されるファイルは次のとおりです。

• backup-my.cnf: バックアップに適用される重大な構成パラメータを記録します。これらのパラメータ値はリストア操作中に使用され、その結果、その間に my.cnf ファイルに変更があったかどうかとは無関係に元の値が使用されます。

• meta/backup_create.xml: コマンド行引数と、バックアップが作成された環境を一覧表示します。

• meta/backup_content.xml: バックアップデータのファイルおよびデータベース定義の基本メタデータ。

• server-my.cnf: デフォルト以外の値に設定された、バックアップ対象サーバーのグローバル変数の値が含まれます。

• server-all.cnf: バックアップ対象サーバーのすべてのグローバル変数の値が含まれます。

バックアップディレクトリ内のすべてのファイルの詳細は、表1.1「MySQL Enterprise Backup 出力ディレクトリ内のファイル」を参照してください。

単一ファイルバックアップ

ワークフローによっては、元のインスタンス内のファイルごとに個別のファイルを生成する一般的なバックアップではなく、単一ファイルのバックアップを実行できます。単一ファイル形式のほうが簡単に、別のシステムへの転送や圧縮と圧縮解除を行え、バックアップ対象ファイルが後から誤って削除されないようにすることができます。完全リストアの実行は、複数ファイルのバックアップと同じくらい高速です。個々のファイルのリストアは、複数ファイルのバックアップより遅くなる可能性があります。手順については、セクション3.3.5「単一ファイルバックアップの作成」を参照してください。