DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

Percona XtraBackupを使用したMySQL増分バックアップの設定

Percona XtraBackupの増分バックアップを、フルバックアップ、LSNチェーン、準備手順、コピーバックを用いて構築および復元します。

Percona XtraBackupを使用したMySQL増分バックアップの設定

Percona XtraBackup（PXB）は、InnoDBデータを持つMySQL互換サーバーのホットバックアップを取得できます。フルバックアップは簡単ですが、大規模なデータベースでは毎晩同じページをコピーしないように、増分バックアップが必要になることがよくあります。

このガイドでは、フルベースバックアップ、チェーンされた増分バックアップ、および各増分を順番に適用する復元シーケンスのコマンドについて説明します。

Percona XtraBackupの増分メカニズムを理解する

PXBは、InnoDBストレージエンジンの内部動作、特にログシーケンス番号（LSN）を使用した変更の追跡に依存しています。すべてのInnoDBページにはLSNがタグ付けされています。PXBが増分バックアップを実行するとき、前回のバックアップ時に記録されたLSNよりも大きいLSNを持つページのみを記録します。

重要なのは、増分バックアップには開始点を確立するためのフルベースバックアップが必要であるということです。後続のすべての増分バックアップはチェーンされ、直前のバックアップ（ベースバックアップまたは別の増分バックアップ）を参照します。

主要なファイルと概念

  • LSN（ログシーケンス番号）： 変更の開始位置と終了位置を決定するために使用されるマーカー。
  • xtrabackup_checkpoints： すべてのバックアップ中に作成されるファイルで、to_lsn（バックアップ終了時に到達したLSN）と、増分バックアップの場合はfrom_lsn（開始LSN）が含まれます。
  • --incremental-basedir： 増分実行時に使用される必須のフラグで、PXBに前回のバックアップのディレクトリを指定します（開始LSNを決定します）。

ステップ1：フルベースバックアップの実行

増分スナップショットを取得する前に、完全で一貫性のあるベースバックアップを作成する必要があります。これにより、バックアップチェーン全体の基盤が確立されます。

まず、フルバックアップ用の明確なディレクトリを定義します。

# フルバックアップのベースディレクトリを定義
BASE_DIR="/data/backups/2023-10-01_FULL"

# ディレクトリを作成
mkdir -p $BASE_DIR

# フルバックアップを実行
xtrabackup --backup \
  --target-dir=$BASE_DIR \
  --user=root --password=secret_password \
  --datadir=/var/lib/mysql

# フルバックアップのLSNを確認
cat $BASE_DIR/xtrabackup_checkpoints | grep 'to_lsn'

注： バックアッププロセスを開始するとき、target-dirは空であるか、存在しない必要があります。必要な権限はMySQLとXtraBackupのバージョンによって異なるため、rootを再利用する代わりに、Perconaの現在の権限ガイダンスに従って専用のバックアップユーザーを作成してください。

ステップ2：最初の増分バックアップの取得

最初の増分バックアップを実行するには、--incremental-basedirフラグを使用してフルベースバックアップディレクトリを参照する必要があります。PXBはベースバックアップからto_lsnを読み取り、その時点以降に変更されたページのみをコピーします。

# 最初の増分バックアップのディレクトリを定義
INCREMENTAL_1_DIR="/data/backups/2023-10-02_INC1"

# フルベースを参照して増分バックアップを実行
xtrabackup --backup \
  --target-dir=$INCREMENTAL_1_DIR \
  --incremental-basedir=/data/backups/2023-10-01_FULL \
  --user=root --password=secret_password

ステップ3：後続の増分バックアップのチェーン

後続の増分バックアップ（INC2、INC3など）の場合、--incremental-basedirは直前の増分バックアップディレクトリを指す必要があります。

INC1以降の変更に基づいてINC2を作成する場合：

# 2番目の増分バックアップのディレクトリを定義
INCREMENTAL_2_DIR="/data/backups/2023-10-03_INC2"

# 前の増分バックアップ（INC1）を参照して増分バックアップを実行
xtrabackup --backup \
  --target-dir=$INCREMENTAL_2_DIR \
  --incremental-basedir=/data/backups/2023-10-02_INC1 \
  --user=root --password=secret_password

このチェーンは、シーケンスを維持している限り続きます。チェーンのいずれかのリンクが壊れている（つまり、ディレクトリがない）場合、復元プロセスは失敗します。

復元：増分変更の適用

増分バックアップセットの復元は、変更をベースバックアップに順次適用する複数ステップのプロセスです。フルバックアップとは異なり、増分バックアップをデータディレクトリに直接コピーすることはできません。

復元フェーズ1：ベースバックアップの準備

まず、ベースバックアップを準備する必要があります。これは通常、データの安全性を確保するために一時的なステージング領域で行われます。

ベースバックアップを準備するとき、PXBは2つの必須アクションを実行します。

  1. コミットされたトランザクション（REDOログ）を適用します。
  2. コミットされていないトランザクションをロールバックします。

--prepareフラグを使用しますが、重要なのは--apply-log-onlyフラグを追加することです。これにより、PXBがコミットされていないトランザクションをロールバックするのを防ぎます。これは、後続の増分ログが復元を完了するためにそれらのトランザクションフラグメントを必要とするためです。

# ステージングディレクトリを定義
RESTORE_TARGET="/data/restore_staging"

# フルベースバックアップファイルをステージング領域にコピー
rsync -avr /data/backups/2023-10-01_FULL/ $RESTORE_TARGET

# ベースバックアップを準備し、増分のために準備完了状態を維持
xtrabackup --prepare --target-dir=$RESTORE_TARGET --apply-log-only

# 確認メッセージを探す：'completed OK!'

復元フェーズ2：増分バックアップを順次適用

次に、各増分バックアップを取得した正確な時系列順に適用します。各コマンドは、ステージングディレクトリ（現在変更中のベースバックアップ）を参照し、特定の増分スナップショットを指す--incremental-dirフラグを使用する必要があります。

# 増分1を適用
xtrabackup --prepare --target-dir=$RESTORE_TARGET \
  --incremental-dir=/data/backups/2023-10-02_INC1 \
  --apply-log-only

# 増分2を適用
xtrabackup --prepare --target-dir=$RESTORE_TARGET \
  --incremental-dir=/data/backups/2023-10-03_INC2 \
  --apply-log-only

# ... 必要なすべての増分に対して続行 ...

復元フェーズ3：準備の最終確定

最後の目的の増分スナップショットが適用されたら、--apply-log-onlyフラグなしで最終準備手順を実行します。これにより、PXBは最終クリーンアップを実行し、バックアップシーケンス全体でまだコミットされていないトランザクションをロールバックして、一貫性のある状態にします。

# 準備を最終確定（--apply-log-onlyなし）
xtrabackup --prepare --target-dir=$RESTORE_TARGET

# 重要：'xtrabackup: Recovery completed OK!'を示す最終確認を探す

復元フェーズ4：MySQLへのデータのコピーバック

準備が正常に完了した後、ステージングディレクトリ（$RESTORE_TARGET）内のデータは一貫性があり、MySQLサーバーで使用できる状態になります。

  1. MySQLサービスを停止します。
  2. MySQLデータディレクトリが空であるか、バックアップされていることを確認します（オプション：許可されている場合は--move-backオプションを使用できますが、復元には--copy-backの方が安全です）。
  3. xtrabackup --copy-backを使用してファイルを移動します。
  4. パーミッションを修正します。
  5. MySQLを再起動します。
# MySQLサービスを停止
sudo systemctl stop mysql

# 準備されたファイルをMySQLデータディレクトリにコピーバック
xtrabackup --copy-back --target-dir=$RESTORE_TARGET

# ファイルの適切な所有権を確保
sudo chown -R mysql:mysql /var/lib/mysql

# MySQLを起動
sudo systemctl start mysql

増分バックアップ管理のベストプラクティス

自動化とスクリプト化

増分バックアップ戦略は、完全に自動化されている場合に最も効果的です。スクリプトはLSNチェーンを自動的に管理し、--incremental-basedirフラグに使用する最新のバックアップディレクトリを動的に識別する必要があります。

保持ポリシー

増分チェーンは非常に長くなる可能性があり、復元が遅く、脆弱になります。新しいフルバックアップを取得して、定期的にチェーンをロールオーバーします。一部のチームは、祖父-父-子の保持モデルの下で、毎週および毎月のフルバックアップも保持します。

圧縮とスロットル

非常にビジーなサーバーの場合は、バックアップフェーズ中に--throttleオプションを使用してI/O操作を制限することを検討してください。--compressを使用してバックアップサイズを削減します。これは、増分バックアップによって生成されるデータセットが小さい場合に非常に有益です。

# 圧縮とスロットルの例
xtrabackup --backup \
  --target-dir=$INCREMENTAL_3_DIR \
  --incremental-basedir=$INCREMENTAL_2_DIR \
  --compress \
  --throttle=100

検証と監視

復元手順を定期的にテストしてください。復元できないバックアップは役に立ちません。特に新しいフルベースバックアップを開始する前に、増分チェーンが消費するディスク容量を監視します。

まとめ

増分XtraBackupは、チェーンがそのままの場合にのみ機能します。フルバックアップ、フルバックアップに基づく最初の増分、次に前のバックアップに基づく後続の各増分です。復元中は、--apply-log-onlyを使用してベースを準備し、各増分を順番に適用し、--apply-log-onlyなしで最後の準備を1回実行し、その後にのみ準備されたデータをMySQLにコピーバックします。