DevOpsナレッジハブ
DevOpsナレッジハブ

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

Percona XtraBackup (PXB) の増分スナップショットを使用して、高効率な MySQL バックアップの技術を習得しましょう。この包括的なガイドでは、LSN トラッキングに基づいた連続した増分バックアップの設定、実行、および復元の重要な手順を詳しく説明します。最初のフルベースバックアップの実行方法、`--incremental-basedir` を使用した後続の増分チェーンの正しい作成方法、およびマルチフェーズ復元プロセスのナビゲーション方法を学び、大規模データベースのダウンタイムを最小限に抑え、ストレージ管理を最適化します。

46 ビュー

Percona XtraBackupによるインクリメンタルMySQLバックアップの設定

Percona XtraBackup (PXB) は、MySQL、MariaDB、およびPercona Serverインスタンスのノンブロッキング・ホットバックアップを実行するための業界標準です。フルバックアップは不可欠ですが、大規模データベースではダウンタイムとストレージ使用量を最小限に抑えるための効率的な戦略が必要です。インクリメンタルバックアップは、最後の正常なバックアップ以降に発生したデータの変更のみをキャプチャすることで、この効率性を提供します。

このガイドでは、PXBを活用して堅牢なインクリメンタルバックアップ戦略を実装する方法を解説します。コアコンセプト、順次インクリメンタルスナップショットを実行するために必要なコマンド、および正常なリストアに必要な複数ステップのプロセスについて説明します。

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 \n  --target-dir=$BASE_DIR \n  --user=root --password=secret_password \n  --datadir=/var/lib/mysql

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

注意: バックアッププロセスを開始する際、target-dirは空であるか、存在しない必要があります。常に適切な権限（例：RELOAD、LOCK TABLES、PROCESS、SUPER権限）を持つ資格情報を使用してください。

ステップ2：最初のインクリメンタルバックアップの取得

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

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

# フルベースを参照してインクリメンタルバックアップを実行
xtrabackup --backup \n  --target-dir=$INCREMENTAL_1_DIR \n  --incremental-basedir=/data/backups/2023-10-01_FULL \n  --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 \n  --target-dir=$INCREMENTAL_2_DIR \n  --incremental-basedir=/data/backups/2023-10-02_INC1 \n  --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フラグを使用する必要があります。

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

# Incremental 2を適用
xtrabackup --prepare --target-dir=$RESTORE_TARGET \n  --incremental-dir=/data/backups/2023-10-03_INC2 \n  --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サービスの停止
service mysql stop

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

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

# MySQLの起動
service mysql start

インクリメンタルバックアップ管理のベストプラクティス

自動化とスクリプティング

インクリメンタルバックアップ戦略は、完全に自動化された場合に最も効果的です。スクリプトは、--incremental-basedirフラグに使用する最新のバックアップディレクトリを動的に識別することにより、LSNの連鎖を自動的に管理する必要があります。

リテンションポリシー

インクリメンタルチェーンは非常に長くなる可能性があり、リストアが遅くなることがあります。一般的なベストプラクティスは、GFS（Grandfather-Father-Son）戦略または差分インクリメンタルバックアップ（すべてのインクリメントがフルベースを参照するもの）です。定期的に、新しいフルバックアップを実行してチェーンをロールオーバーし、新しく短いチェーンを開始します。

圧縮とスロットリング

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

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

検証と監視

リストア手順は必ず定期的にテストしてください。リストアできないバックアップは役に立ちません。新しいフルベースバックアップを開始する前も含め、インクリメンタルチェーンが消費するディスク容量を監視してください。