Documentation Home
MySQL Enterprise Backup ユーザーズガイド (バージョン 3.11)
Download this Manual
PDF (US Ltr) - 1.3Mb
PDF (A4) - 1.3Mb
HTML Download (TGZ) - 164.9Kb
HTML Download (Zip) - 191.2Kb


5.1.8 増分バックアップオプション

増分バックアップの概要とこれらのオプションに関する使用情報については、セクション3.3.2「増分バックアップの作成」を参照してください。

増分バックアップを取得するには、--incremental-backup-dir と一緒に、--incremental または --incremental-with-redo-log-only を指定します。指定した LSN 後に変更されたすべての InnoDB が増分バックアップにコピーされます。--incremental または --incremental-with-redo-log-only の選択に応じて、ほかのオプションが必要であったり、推奨されたりします。

  • --incremental

    関連付けられた backup または backup-to-image 操作が増分であることを指定します。さらに、--incremental-base オプションまたは --start-lsn オプションと --incremental-backup-dir オプションの組み合わせのいずれかが必要です。

    増分の観点は InnoDB テーブルにのみ適用されます。デフォルトで、すべての InnoDB 以外のファイルと .frm ファイルも増分バックアップに含まれます。増分バックアップで InnoDB 以外のデータを除外するには、--only-innodb オプションを使用します。

  • --incremental-with-redo-log-only

    backup または backup-to-image 操作の増分バックアップの代替形式を指定します。さらに、--incremental-base オプションまたは --start-lsn オプションと --incremental-backup-dir オプションの組み合わせのいずれかが必要です。

    このオプションによって実行される増分バックアップには、--incremental オプションと異なるパフォーマンス特性と操作上の制限があります。

    • InnoDB テーブルへの変更は、InnoDB Redo ログの内容に基づいて判断されます。Redo ログファイルは、事前にわかっている固定のサイズを持つため、データベースのサイズ、DML アクティビティーの量、Redo ログファイルのサイズによっては、変更されたページを見つけるために、InnoDB のテーブルスペースファイルをスキャンするよりも、それらからの変更を読み取る方が必要な I/O が少なくなる可能性があります。

    • Redo ログファイルは循環バッファーとして動作し、新しい DML 操作が行われると、古い変更の記録が上書きされるため、ワークロードに対して生成されるログファイルのサイズと Redo データの量に依存する予測可能なスケジュールで、新しい増分バックアップを取得する必要があります。そうしないと、Redo ログは前回の増分バックアップからのすべての変更を記録するために十分なだけさかのぼらないことがあります。この場合、mysqlbackup コマンドはすぐに続行できないことを判断し、エラーを返します。バックアップスクリプトは、エラーをキャッチでき、代わりに --incremental オプションで増分バックアップを実行します。

      例:

      • Redo ログのサイズを計算するには、コマンド SHOW VARIABLES LIKE 'innodb_log_file%' を発行し、出力に基づいて、innodb_log_file_size 設定と innodb_log_files_in_group を乗算します。物理レベルで Redo ログサイズを計算するには、MySQL インスタンスの datadir ディレクトリを調べ、パターン ib_logfile* に一致するファイルのサイズを合計します。

      • InnoDB LSN 値は Redo ログに書き込まれるバイト数に対応します。特定の時点で LSN をチェックするには、コマンド SHOW ENGINE INNODB STATUS を発行し、LOG 見出しの下を調べます。バックアップ戦略を計画する場合、LSN 値を定期的に記録し、現在の値から以前の値を引いて、毎時、毎日などに生成される Redo データの量を計算します。

      MySQL 5.5 以前では、MySQL サーバーが正常にシャットダウンせずに強制終了した場合に、起動時間が長くなるのを避けるため、Redo ログをかなり小さく維持することが一般的な方法でした。MySQL 5.5 以降では、「InnoDB 構成変数の最適化」に説明するように、クラッシュリカバリのパフォーマンスが大幅に向上しています。それらのリリースでは、Redo ログファイルを大きくすることが、バックアップ戦略やデータベースワークロードに役立つ場合に、そうすることができます。

    • この増分バックアップの種類は、標準 --incremental オプションとして、小さすぎる --start-lsn 値を許容しません。たとえば、フルバックアップを作成できず、その後すべて同じ --start-lsn 値を使用する一連の --incremental-with-redo-log-only バックアップを作成します。次の増分バックアップの開始 LSN として、前回のバックアップの正確な終了 LSN を指定してください。任意の値を使用しないでください。

      注記

      このオプションを使用して、連続した増分バックアップ間で、LSN 値を正確に一致させるため、Oracle では、--incremental-with-redo-log-only オプションを使用する場合に常に --incremental-base オプションを使用することをお勧めします。

    • 特定の MySQL インスタンスに対し、この増分バックアップの種類が現実的であり、効率的であるか判断するには:

      • InnoDB Redo ログファイル内のデータの変更の速度を測定します。LSN を定期的にチェックし、一定の時間や日数の間に累積する Redo データの量を確認します。

      • Redo ログの累積率と Redo ログファイルのサイズを比較します。この率を使用して、増分バックアップを取得する頻度を確認し、Redo ログで履歴データを使用できないために、バックアップが失敗する可能性を避けます。たとえば、1 日あたり 1G バイトの Redo ログデータを生成し、Redo ログファイルの合計サイズが 7G バイトである場合、増分バックアップを週 1 回以上の頻度にスケジュールします。突然の更新の急増によって、通常より多くの Redo が生成された場合の可能性のある問題を避けるため、毎日または 2 日おきに増分バックアップを実行した方がよいと考えられます。

      • --incremental オプションと --incremental-with-redo-log-only オプションの両方を使用して、増分バックアップの時間をベンチマークテストし、Redo ログバックアップ技法が従来の増分バックアップ方法より高速かつ少ないオーバーヘッドで実行するかどうかを確認します。結果は、データのサイズ、DML アクティビティーの量、Redo ログファイルのサイズによって異なることがあります。現実的なデータボリュームと現実的なワークロードを実行するサーバーでテストを行なってください。たとえば、巨大な Redo ログファイルがあり、増分バックアップの過程でそれらを読み取ることは、従来の増分技法を使用して、InnoDB データファイルを読み取る場合と同じくらい時間がかかる可能性があります。逆に、データボリュームが大きい場合、すべてのデータファイルを読み取って、わずかな変更されたページを見つけることは、はるかに小さな Redo ログファイルを処理するよりも非効率的である可能性があります。

    --incremental オプションと同様に、増分の観点は InnoDB テーブルにのみ適用されます。デフォルトで、すべての InnoDB 以外のファイルと .frm ファイルも増分バックアップに含まれます。増分バックアップで InnoDB 以外のデータを除外するには、--only-innodb オプションを使用します。

  • --incremental-base=mode:argument

    プロパティ
    コマンド行形式 --incremental-base=mode:argument
    文字列

    このオプションを使用すると、mysqlbackup は増分バックアップの実行に必要な情報を --start-lsn オプションからではなく、バックアップディレクトリ内のメタデータから取得します。これにより、一連の増分バックアップの実行時に、絶え間なく変化し、予測不可能な LSN 値を指定する必要を避けられます。代わりに、出力構文のモード引数の組み合わせによって、前回のバックアップディレクトリを見つける方法を指定します。代替方法:

    • dir:directory_path

      プリフィクス dir: の後にディレクトリパスを指定します。パス引数は、前回のバックアップからのデータが格納されているルートディレクトリを指します。最初の増分バックアップでは、フルバックアップを保持するディレクトリを指定し、2 回目の増分バックアップでは、最初の増分バックアップを保持するディレクトリを指定するというようになります。

    • history:last_backup

      プリフィクス history: の後に、このモードで唯一の有効な引数 last_backup を指定します。これにより、mysqlbackup に、該当するインスタンスの backup_history テーブルに記録されている最後の成功したバックアップから end_lsn 値をクエリーさせます。

      警告

      前回のバックアップが --no-connection オプションによって取得されたフルバックアップであった場合、history: モードは使用しないでください。これは常にバックアップ履歴の記録をオフにし、--incremental-base オプションのこのモードを使用した後続の増分バックアップでエラーが発生する可能性があります。

  • --start-lsn=LSN

    プロパティ
    コマンド行形式 --start-lsn=LSN
    数値

    増分バックアップでは、前回のバックアップに含まれる最高の LSN 値を指定します。この値は、前回のバックアップ操作の出力から、または前回のバックアップ操作の backup_history テーブルの end_lsn カラムから取得できます。常に --incremental オプションと一緒に使用し、--incremental-base オプションを使用する場合に必要ではなく、増分バックアップに --incremental-with-redo-log-only メカニズムを使用する場合に推奨されません。

  • --incremental-backup-dir=PATH

    プロパティ
    コマンド行形式 --incremental-backup-dir=PATH
    ディレクトリ名

    増分バックアップからのデータを格納する場所を指定します。これは、後続の増分バックアップに --incremental-base を使用した場合に、そのオプションで指定した場所と同じになります。

例 5.4 増分バックアップ

これらの例に、増分バックアップで使用される一般的なオプションの組み合わせを示します。

mysqlbackup --incremental \
  --incremental-backup-dir=/var/mysql/backup/latest \
  --incremental-base=dir:/var/mysql/backup/previous \
  ... backup

mysqlbackup --incremental-with-redo-log-only \
  --incremental-backup-dir=/var/mysql/backup/latest \
  --incremental-base=dir:/var/mysql/backup/previous \
  ... backup

mysqlbackup --incremental --start-lsn=12345 \
  --incremental-backup-dir=/var/mysql/backup/inc \
  ... backup

mysqlbackup --incremental-with-redo-log-only --start-lsn=12345 \
  --incremental-backup-dir=/var/mysql/backup/inc \
  ... backup