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


3.3.2 増分バックアップの作成

増分バックアップは、前回のバックアップ以降に変更のあったデータだけをバックアップします。この手法は、バックアップ戦略の設計での柔軟性を高め、バックアップに必要なストレージを軽減します。

増分バックアップは通常、完全バックアップより小さく、時間がかからないため、頻繁なバックアップジョブに適しています。増分バックアップを頻繁に取得しておけば、常にデータベースを、数時間または数日前と同じ状態にリストアでき、完全バックアップを頻繁に取得する場合と同じだけのデータベースサーバーでのロードまたはストレージオーバーヘッドは不要になります。

注記

増分バックアップは常に既存のバックアップファイルのセットに追加するため、増分バックアップを行う前に、少なくとも 1 つの完全バックアップを作成してください。

増分バックアップは、mysqlbackup コマンドのオプションで有効になります。単純な増分バックアップの場合、--incremental オプションを指定します。代わりの方法では、--incremental-with-redo-log-only オプションを使用しますが、ユーザー側で追加の計画が必要になります。

また、前の完全または増分バックアップの特定の時点を指定します。便宜上、--incremental-base オプションを使用して、前のバックアップディレクトリに格納されたメタデータから必要なログシーケンス番号 (LSN) を自動的に取得できます。または、--start-lsn オプションを使用し、前の完全または増分バックアップから終了 LSN を使用して明確な LSN 値を指定できます。

バックアップデータをリストアする準備を行うには、各増分バックアップを元の完全バックアップと組み合わせます。通常、指定された期間の経過後に新しい完全バックアップを実行し、そのあとで古い増分バックアップデータを破棄できます。

増分バックアップのログの適用手順を実行するときに、オプションシーケンス --incremental apply-log と、2 つの MySQL 構成ファイルへのパス (最初に、更新している完全バックアップを指す .cnf ファイルと、次に増分バックアップデータファイルを指す .cnf ファイル) を指定します。前回の完全バックアップ以降に複数の増分バックアップを取得していた場合は、このようなログの適用ステップを順に複数実行して、完全バックアップを完全に最新の状態にすることができます。

増分バックアップの領域に関する考慮事項

増分バックアップ機能は主に、InnoDB テーブルや、読み取り専用またはまれにしか更新されない非 InnoDB テーブルを対象としています。非 InnoDB ファイルでは、前回のバックアップ以降にファイルに変更があった場合、ファイル全体が増分バックアップに含まれます。

--compress オプションでは増分バックアップを実行できません。

増分バックアップは、テーブルの行ではなく、InnoDB データファイル内のページのレベルで変更を検出します。変更のあった各ページがバックアップされます。したがって、領域と時間の節約は、変更された InnoDB の行またはカラムの割合に正確には比例しません。

増分バックアップの例

この例では、mysqlbackup コマンドを使用して、すべてのデータベースとテーブルを含む MySQL Server の増分バックアップを作成します。--incremental-base オプションを使用したものと、--start-lsn オプションを使用したものの 2 つの代替例を示します。

--incremental-base オプションを使用した場合、あるバックアップと次のバックアップの間で LSN 値を追跡する必要はありません。代わりに、前回のバックアップ (完全または増分) のディレクトリを指定し、mysqlbackup が、以前のバックアップのメタデータに基づいてこのバックアップの開始点を算出します。既知のディレクトリ名のセットが必要なため、--with-timestamp オプションを使用するのではなく、ハードコード化された名前を使用するか、自身のバックアップスクリプトで名前のシーケンスを生成することができます。

$ mysqlbackup --defaults-file=/home/pekka/.my.cnf --incremental \
  --incremental-base=dir:/incr-backup/wednesday \
  --incremental-backup-dir=/incr-backup/thursday \
  backup
...many lines of output...
mysqlbackup: Backup created in directory '/incr-backup/thursday'
mysqlbackup: start_lsn: 2654255717
mysqlbackup: incremental_base_lsn: 2666733462
mysqlbackup: end_lsn: 2666736714

101208 17:14:58 mysqlbackup: mysqlbackup completed OK!

--start-lsn オプションでは、前回のバックアップの LSN を記録する必要がありますが、前回のバックアップの場所があまり重要でないため、--with-timestamp を使用して、名前の付けられたサブディレクトリを自動的に作成することができます。

$ mysqlbackup --defaults-file=/home/pekka/.my.cnf --incremental \
  --start-lsn=2654255716 \
  --with-timestamp \
  --incremental-backup-dir=/incr-backup \
  backup
...many lines of output...
mysqlbackup: Backup created in directory '/incr-backup/2010-12-08_17-14-48'
mysqlbackup: start_lsn: 2654255717
mysqlbackup: incremental_base_lsn: 2666733462
mysqlbackup: end_lsn: 2666736714

101208 17:14:58 mysqlbackup: mysqlbackup completed OK!

--incremental オプションを使用するどの箇所でも、代わりに --incremental-with-redo-log-only オプションを使用できます。--incremental-with-redo-log-only は、--incremental オプションより正確な LSN に依存する程度が大きいため、この種の増分バックアップには、--start-lsn オプションではなく --incremental-base オプションを使用してください。

このような代わりの増分バックアップが機能するには、前回の増分バックアップ以降のすべての変更が Redo ログに存在し、上書きされないようにする必要があるため、変更された情報が十分に少量で、Redo ログファイルが十分に大きいことが必要です。これらの要件を検証する方法については、--incremental-with-redo-log-only オプションの説明を参照してください。

$ mysqlbackup --defaults-file=/home/pekka/.my.cnf --incremental \
  --incremental-base=dir:/incr-backup/wednesday \
  --incremental-backup-dir=/incr-backup/thursday \
  backup
...many lines of output...
mysqlbackup: Backup created in directory '/incr-backup/thursday'
mysqlbackup: start_lsn: 2654255717
mysqlbackup: incremental_base_lsn: 2666733462
mysqlbackup: end_lsn: 2666736714

101208 17:14:58 mysqlbackup: mysqlbackup completed OK!

通常の増分バックアップからのファイルの一覧については、セクションC.3「増分バックアップのディレクトリ構造例」を参照してください。

もう一度、バックアップを実行していた間に行われた変更を、完全バックアップに適用します。

$ mysqlbackup --backup-dir=/full-backup/2010-12-08_17-14-11 apply-log
..many lines of output...
101208 17:15:10  mysqlbackup: Full backup prepared for recovery successfully!

101208 17:15:10 mysqlbackup: mysqlbackup completed OK!

続いて、増分バックアップから変更を適用します。

$ mysqlbackup --incremental-backup-dir=/incr-backup/2010-12-08_17-14-48 
  --backup-dir=/full-backup/2010-12-08_17-14-11 apply-incremental-backup
...many lines of output...
101208 17:15:12 mysqlbackup: mysqlbackup completed OK!

これで、完全バックアップディレクトリ内のデータファイルは全面的に、前回の増分バックアップ時点の最新の状態になっています。

この例には増分バックアップが示されています。前回実行した完全バックアップで、もっとも高い LSN が 2638548215 だったことがレポートされました。

mysqlbackup: Was able to parse the log up to lsn 2638548215

ここではコマンドでもう一度その番号を指定します。増分バックアップには、指定した LSN のに行われたすべての変更が含まれます。

$ mysqlbackup --defaults-file=/home/pekka/.my.cnf --incremental \
  --start-lsn=2638548215 \
  --incremental-backup-dir=/incr-backup/2010-12-08_17-14-48 \
  --backup-dir=/full-backup/2010-12-08_17-14-11 \
	backup
...many lines of output...
mysqlbackup: Scanned log up to lsn 2654252454.
mysqlbackup: Was able to parse the log up to lsn 2654252454.
mysqlbackup: Maximum page number for a log record 0
mysqlbackup: Backup contains changes from lsn 2638548216 to lsn 2654252454
101208 17:12:24  mysqlbackup: Incremental backup completed!

次のステップ:

  • mysqlbackup: Was able to parse the log up to lsn LSN_number などの、バックアップの終わりに表示されるメッセージ内の LSN 値を書き留めてください。この増分バックアップのあとに行われた変更の増分バックアップを実行するときに、この値を指定します。

  • いつでもバックアップをリストアできるよう、バックアップファイルに増分バックアップを適用します。最初にバックアップデータを別のサーバーに移動して、データベースサーバー自体でのこの操作の CPU および I/O オーバーヘッドを回避できます。

  • 定期的に、データベースアクティビティーの日付または量で判断し、さらに増分バックアップを取得します。

  • オプションで、完全、非圧縮、または圧縮バックアップを取得することによって、サイクルを定期的に開始しなおしてください。通常、このマイルストーンは、もっとも古いバックアップデータをアーカイブおよびクリアできるときに行われます。


User Comments
Sign Up Login You must be logged in to post a comment.