DBA と開発作業には通常、テーブル、行、カラム、データディクショナリなどの論理構造が含まれます。バックアップでは、これらの構造がファイルによってどのように表されているかに関する物理的な詳細を理解しておく必要があります。
表 1.1 MySQL Enterprise Backup 出力ディレクトリ内のファイル
ファイル名、パターン、または拡張子 |
元のデータファイルとの関係 |
注 |
---|---|---|
|
InnoDB システムテーブルスペース。複数の InnoDB テーブルおよび関連したインデックスが含まれます。 |
バックアップの進行中に元のファイルが変更される可能性があるため、 |
|
InnoDB file-per-table テーブルスペース。それぞれに単一の InnoDB テーブルおよび関連したインデックスが含まれます。 |
|
|
MySQL データディレクトリからの InnoDB データファイルの圧縮された形式。 |
圧縮バックアップで
|
|
すべての MySQL テーブルに関するメタデータを保持します。 |
これらのファイルがコピーされている間、データベースは読み取り専用状態になります。これらのファイルは変更なしにコピーされます。 |
|
MyISAM テーブルデータ。 |
これらのファイルがコピーされている間、データベースは読み取り専用状態になります。これらのファイルは変更なしにコピーされます。 |
|
MyISAM インデックスデータ。 |
これらのファイルがコピーされている間、データベースは読み取り専用状態になります。これらのファイルは変更なしにコピーされます。 |
|
CSV テーブルのメタデータ。 |
これらのファイルは変更なしにコピーされます。mysqlbackup で作成される |
|
CSV テーブルのデータ。 |
これらのファイルは変更なしにコピーされます。mysqlbackup で作成される |
|
MERGE ストレージエンジンはほかのテーブルを参照します。 |
これらのファイルがコピーされている間、データベースは読み取り専用状態になります。これらのファイルは変更なしにコピーされます。 |
|
トリガーパラメータ。 |
これらのファイルがコピーされている間、データベースは読み取り専用状態になります。これらのファイルは変更なしにコピーされます。 |
|
トリガー名前空間情報。 |
これらのファイルがコピーされている間、データベースは読み取り専用状態になります。これらのファイルは変更なしにコピーされます。 |
|
データベース構成情報。 |
これらのファイルがコピーされている間、データベースは読み取り専用状態になります。これらのファイルは変更なしにコピーされます。 |
|
パーティション化されたテーブルの定義。 |
これらのファイルがコピーされている間、データベースは読み取り専用状態になります。これらのファイルは変更なしにコピーされます。 |
|
アーカイブストレージエンジンメタデータ。 |
これらのファイルがコピーされている間、データベースは読み取り専用状態になります。これらのファイルは変更なしにコピーされます。 |
|
アーカイブストレージエンジンデータ。 |
これらのファイルがコピーされている間、データベースは読み取り専用状態になります。これらのファイルは変更なしにコピーされます。 |
|
MySQL データファイルのレイアウトを指定する構成パラメータを記録します。 |
リストア操作で、バックアップが作成された時点と同じレイアウトを再生成するために使用されます。 |
|
MySQL データディレクトリからの |
InnoDB ログファイル ( |
|
|
|
|
最初のバックアップ後、apply-log フェーズ中にバックアップディレクトリに作成されます。 |
これらのファイルは元のデータディレクトリからコピーされるのではなく、 |
|
バックアップ対象サーバーからの各 .isl ファイルの名前を変更したバージョン。 |
|
|
|
複数セットのバックアップデータを同一の主要なバックアップディレクトリ下で継続的に利用する場合は必ず、 |
|
元の MySQL インスタンスからのすべてのデータファイルとデータベースサブディレクトリを格納するサブディレクトリ。 |
mysqlbackup コマンドによって、バックアップディレクトリ下に作成されます。 |
サーバーからのバイナリログファイル。これらはデフォルトでバックアップに含められます。これらにより、サーバーのスナップショットを取得できるため、サーバーを正確にクローン化できます。完全バックアップを基本として使用しながら、増分バックアップに含まれるバイナリログファイルは、前回の完全バックアップ以降の特定の時点の状態にデータベースをリストアするポイントインタイム・リカバリ (PITR) に使用できます。詳細は、セクション4.3「ホットバックアップからのポイントインタイム・リカバリ」を参照してください。 |
バックアップディレクトリ下の 注記
一部の既知の問題のため、オフラインバックアップを作成するときや、
|
|
リレーログファイル |
スレーブサーバーからのリレーログファイル。これらは、デフォルトでスレーブサーバーのバックアップに含められます。これらが含まれているため、スレーブがリストアされているときに、マスターからリレーログを取り出すために必要な時間とリソースが節約されます。 |
バックアップディレクトリ下の |
スレーブステータスログファイル | 通常、これらのファイルは master.info および relay-log.info という名前が付けられ、デフォルトで、レプリケーションを行うときにスレーブデータベースのバックアップに含められます。詳細は、スレーブステータスログを参照してください。 |
バックアップディレクトリ下の datadir ディレクトリの下に保存されます。オフラインバックアップの場合、mysqlbackup がこれらのファイルを見つけてバックアップに含めることができるように、--master-info-file オプションと --relaylog-info-file オプションを使用して、情報ファイルの絶対パスを指定してください (オプションのデフォルト値と異なる場合)。 |
|
|
バックアップデータディレクトリがゼロバイトのファイルのみで構成され、最上位のディレクトリに単一の巨大なデータファイルがある場合は、単一ファイルのバックアップが存在しています。内部のコンテンツを損失または損傷することなくイメージファイルを移動し、続いて |
|
MySQL データディレクトリからコピーされます。 |
デフォルトで、MySQL データディレクトリ内の認識されないファイルはすべて、バックアップにコピーされます。このようなファイルを除外するには、 |
|
バックアップに関するメタデータを含むファイルを格納したサブディレクトリ。 |
mysqlbackup コマンドによって、バックアップディレクトリ下に作成されます。次に一覧表示されたすべてのファイルは、 |
|
バックアップに関する重要な情報が保持されます。mysqlbackup コマンド専用です。MySQL Enterprise Backup 3.6 以前では、この情報は |
mysqlbackup コマンドは、apply-log フェーズや restore フェーズなど、最初のバックアップ後の操作中にこのファイルを参照し、多くの場合更新します。 |
|
|
このファイルはいったん生成されると、どの段階でも変更されません。 |
|
コマンド行引数と、バックアップが作成された環境を一覧表示します。このファイルの詳細は、セクション10.5「MySQL Enterprise Backup マニフェストの使用」を参照してください。 |
このファイルはいったん作成されると、変更されません。 |
|
バックアップデータのファイルおよびデータベース定義の基本メタデータ。バックアップ対象サーバー上で定義されているすべてのプラグインの詳細も含まれます。ユーザーはこの詳細から、同じプラグインがリストアのターゲットサーバー上でも同じように定義されていることを確認する必要があります。このファイルの詳細は、セクション10.5「MySQL Enterprise Backup マニフェストの使用」を参照してください。 |
このファイルはいったん作成されると、変更されません。 |
|
|
コメントは、このバックアップジョブの目的または特別な考慮事項について記すためにユーザーが指定します。 |
|
GTID を有効にしたサーバーから取得されたバックアップを指定します。 |
GTID は、MySQL 5.6 以上のレプリケーション機能です。詳細は、グローバルトランザクション識別子を使用したレプリケーションを参照してください。GTID を有効にしたサーバーをバックアップすると、バックアップディレクトリに |
server-my.cnf |
デフォルト以外の値に設定された、バックアップ対象サーバーのグローバル変数の値が含まれます。このファイルまたは |
警告
ファイルを使用してターゲットサーバーを再起動するときには、ターゲットサーバーが誤って間違ったファイルの場所を使用しないようにするために、 |
server-all.cnf |
バックアップ対象サーバーのすべてのグローバル変数の値が含まれます。このファイルまたは |
警告
ファイルを使用してターゲットサーバーを再起動するときには、ターゲットサーバーが誤って間違ったファイルの場所を使用しないようにするために、 |
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「単一ファイルバックアップの作成」を参照してください。