A.1 MySQL Enterprise Backup の制限

  • MySQL 5.6 以降のグループコミット機能により、InnoDB Redo ログのフラッシュ操作の頻度が変わるため、InnoDB テーブルからのバックアップデータに関連付けられた特定の時点に影響が及ぶ可能性があります。詳細は、セクションB.4「特定の MySQL バージョンに関する互換性の注意事項」を参照してください。

  • MySQL 5.5 以前では、セクション4.4「単一の .ibd ファイルのバックアップとリストア」で述べているように、個々の InnoDB テーブルをリストアするときには、バックアップ後に MySQL Server でテーブルが破棄または切り取られていないことが必要です。InnoDB テーブルを破棄したり切り取ったりすると内部テーブル ID が変わるため、テーブルが再作成されると、その ID はバックアップデータからのテーブル ID と一致しなくなります。同じシリーズの MySQL Server の、ある一般提供開始 (GA) バージョンから別バージョンにリストアが行われるかぎり、この制限は MySQL 5.6 以降には適用されません。

  • Linux、Unix、および OS X システムで、mysqlbackup コマンドは、バックアップされるファイルのファイル所有権もアクセス許可も記録しません。リストア時、たとえば mysql ではなく root が所有しているなど、これらのファイルの所有権が異なる場合があります。また、たとえばファイル所有者だけではなく全員が読み取り可能であるなど、読み取り/書き込みアクセス許可が異なる場合もあります。バックアップ戦略を計画するときに、MySQL データディレクトリ内のファイルを調べて、それらの所有者とアクセス許可設定が一貫していることを確認してください。リストア操作を実行するときには、suumaskchown、および chmod の適切な組み合わせを使用して、元のファイルと同じ所有者および権限を設定します。

  • 場合によっては、MyISAM テーブルなどの非トランザクションテーブルのバックアップには、コミットされていない追加データが含まれることがあります。autocommit をオフにし、InnoDB テーブルと非トランザクションテーブルの両方を同じトランザクション内で変更した場合、バイナリログ位置が更新される前に、非トランザクションテーブルにデータを書き込めます。トランザクションがコミットされるときにバイナリログ位置が更新されますが、非トランザクションデータは即座に書き込まれます。このようなトランザクションが開かれている間にバックアップが行われた場合、バックアップデータには、非トランザクションテーブルに行われた更新が含まれます。

  • Unix kill -9 コマンドなどで mysqlbackup プロセスが中断された場合、FLUSH TABLES WITH READ LOCK 操作が実行し続けることがあります。この場合、mysql コマンド行から KILL QUERY ステートメントを使用して、FLUSH TABLES WITH READ LOCK ステートメントを強制終了してください。長時間実行するクエリーまたはトランザクションによって、FLUSH TABLES 操作が停止した場合に、この問題が起きる可能性が高くなります。バックアップのタイミングとパフォーマンスに関するガイドラインについては、第5章「mysqlbackup コマンドリファレンスを参照してください。

  • バックアップ操作の進行中は、ALTER TABLETRUNCATE TABLEOPTIMIZE TABLEREPAIR TABLE、および RESTORE TABLE の DDL 操作を実行しないでください。結果として得られたバックアップが破損している可能性があります。

    バックアップと並列して安全に実行できる ALTER TABLE 操作だけが、変化するカラム名やデフォルトのカラム値など、ディスク上のレコードの物理表現に影響しない操作です。

  • MySQL Server でステートメントベースのバイナリログ形式を使用する場合 (デフォルトの動作です)、データベース内に一時テーブルがあるときにバックアップを取得し、これらの一時テーブルを使用して通常のテーブルへの更新または挿入を行うと、バックアップへの MySQL バイナリログの適用が失敗することがあります。つまり、MySQL バイナリログを使用して特定の時点にバックアップをロールフォワードできない可能性があります。これは、物理ファイル名 #sql*.frm が MySQL によりバイナリログに書き込まれる論理テーブル名に一致しないために、一時テーブルがバックアップにコピーされないからです。この問題を回避するには、サーバー上で --binlog-format オプションの値を ROW または MIXED に設定して、バイナリログに行ベースまたは混在形式を使用してください。

  • mysql.backup_history テーブルの engines カラムには、バックアップされたデータベースのストレージエンジンは正しく反映されません。

  • データディレクトリにテーブルを保存するときに、MySQL Server は、あらゆるデータベース名またはテーブル名内のすべての特殊文字に対して変換を実行し、ストレージ用のファイル名を生成します。次に、データベース名およびファイル名に特殊文字 (.-) を含んだ MySQL コマンドの 2 つの例を示します。

    mysql> CREATE TABLE `db.2`.`t.2` (c1 INT) ENGINE=InnoDB;
    mysql> CREATE TABLE `db-3`.`t-3` (c1 INT) ENGINE=InnoDB;

    これらのコマンドで作成されたテーブルは、次のファイルとしてファイルシステムに格納されます。

    db@002e2/t@002e2.ibd
    db@002d3/t@002d3.ibd

    現在、mysqlbackup は、--include-tables オプションと --exclude-tables オプションを使用して与えられたデータベース名およびテーブル名で、同じ変換を実行しません。たとえば、--include-tables="db\.2\.t\.2|db-3\.t-3" を使用すると、前述のテーブルは選択されません。

    回避策として、ユーザーは、データベースのデータディレクトリで目的のテーブルのファイル名を調べ、--include-tables オプションと --exclude-tables オプションの引数で、データベース名としてデータベースディレクトリの変換後の名前を使用し、テーブル名として変換後のファイル名 (ファイル拡張子なし) を使用することができます。たとえば、前述のテーブルの場合、オプション引数 --include-tables="db@002e2\.t@002e2|db@002d3\.t@002d3" で、バックアップに含めるテーブルとして選択します。オプション --exclude-tables で同じ引数を使用すると、これら 2 つのテーブルはバックアップで除外されます。

  • 大量の書き込みワークロード (1 分あたり数ギガバイト程度) を抱える大規模データベースのホットバックアップは、バックアップの進行中にサーバーで生成される大きな Redo ログファイルのために、完了までに長時間かかることがあります。また、Redo ログファイルが mysqlbackup で可能な処理速度よりも速く増大した場合、mysqlbackup が Redo ログサイクルに追いつけず、LSN が mysqlbackup によって読み取られる前にサーバーによって上書きされたときに、バックアップ操作は実際に失敗することがあります。Redo ログの読み取りと書き込みに利用できる I/O リソースが、バックアッププロセス中に不足しているときに、問題は大きくなります。ただし、データベースの少数のテーブルだけが頻繁に変更される場合は、オプティミスティックバックアップ機能で問題が軽減される可能性があります。詳細は、セクション3.3.6「オプティミスティックバックアップの作成」を参照してください。

  • MySQL Server 5.6.10 以前からの圧縮 InnoDB テーブルは、InnoDB ストレージエンジンでのバグのため、MySQL Enterprise Backup 3.9.0 以降ではリストアできません (MySQL Bug System で Bug# 72851 を参照してください)。

  • サーバーからバックアップへバイナリログファイルをコピーしようとすると (3.11.0 以降の MySQL Enterprise Backup のデフォルトの動作です)、増分バックアップの基準である完全バックアップが --no-locking オプションで作成されていた場合は、その増分バックアップは失敗します。回避策として、ユーザーは、この状況で実行される増分バックアップに --skip-binlog オプションを使用する必要があります。

  • サーバーからバックアップへバイナリログファイルをコピーしようとすると (3.11.0 以降の MySQL Enterprise Backup のデフォルトの動作です)、オフラインバックアップは失敗します。回避策として、オフラインバックアップには常に、--skip-binlog オプションを使用してください。

  • MySQL Enterprise Backup を使用して、ネットワークアタッチトストレージ (NAS) デバイスへのバックアップ、またはそこからのリストアを行うことは可能ですが、ネットワーク問題が発生した場合には、バックアップの一貫性とバックアップまたはリストア操作のパフォーマンスが損なわれる恐れがあります。