ローカル バックアップを使用して単一サーバーでデータベース クラスタのクローンを作成する

このページでは、ローカル バックアップを使用して単一サーバーでデータベース クラスタのクローンを作成する方法について説明します。

このページの手順では、ソース Kubernetes データベース クラスタが Google Kubernetes Engine で作成され、バックアップ ディスクが Compute Engine 永続ディスクであることを前提としています。また、ターゲット AlloyDB Omni 単一サーバーが Compute Engine 仮想マシン（VM）にインストールされていることを前提としています。

他の環境を使用している場合は、それぞれのドキュメントを参照して、これらの手順を環境に複製してください。

次のワークフローは、クローン作成手順を示しています。

  1. ソース データベース クラスタのバックアップ ディスクのバックアップ ディスク情報（永続ボリューム名、Compute Engine 永続ディスク ハンドラなど）を特定します。
  2. ソース データベース クラスタのバックアップ ディスクをターゲット サーバーにマウントします。
  3. pgBackRest コマンドを使用して、ソース バックアップにアクセスできることを確認します。
  4. pgBackRest コマンドを使用して、バックアップをターゲット データベース クラスタに復元します。

始める前に

  • 移行元データベース クラスタのバックアップが保存されているバックアップ ディスクにアクセスできることを確認します。
  • 単一サーバー ターゲットの AlloyDB Omni データベース クラスタが作成されます。Kubernetes への AlloyDB Omni のインストールの詳細については、AlloyDB Omni をインストールするをご覧ください。
  • postgres ユーザーとしてデータベースにログインしていることを確認します。

ソース バックアップ ディスク情報を取得する

復元プロセスの一環として、ソース データベース クラスタのバックアップ ディスクの Persistent Volume Claim（PVC）名を決定します。PVC は、Kubernetes 内でアプリケーションの永続ストレージを管理するために使用されます。

次のサンプル コマンドを使用すると、バックアップ ディスクの PVC 名を使用して、基盤となる PV 名と Compute Engine 永続ディスク ハンドラを特定できます。

  1. AlloyDB Omni ソース データベース クラスタを作成した GKE クラスタに接続します。

     kubectl get pvc -n DB_CLUSTER_NAMESPACE | grep DB_CLUSTER_NAME | grep backupdisk

    次のように置き換えます。

    • DB_CLUSTER_NAMESPACE: このバックアップの Kubernetes Namespace。データベース クラスタの名前空間と一致する必要があります。

    • DB_CLUSTER_NAME: このデータベース クラスタの名前（例: my-db-cluster）。

    レスポンスの例を次に示します。

      backupdisk-al-fe8c-dbcluster-sample-0   Bound
  pvc-36d8f05d-ef1a-4750-ac01-9bb330c15b3a   10Gi       RWO            standard-rwo   5d21h
  ```

  2. 前の手順のバックアップ ディスク名（backupdisk-al-fe8c-dbcluster-sample-0 など）を使用して、基盤となる PV 名を確認します。

      kubectl get pvc/PVC_NAME -n DB_CLUSTER_NAMESPACE -o jsonpath={.spec.volumeName}

    次のように置き換えます。

    • PVC_NAME: 前の手順のレスポンスから取得したバックアップ ディスクの PVC 名（例: backupdisk-al-fe8c-dbcluster-sample-0）。

  3. 基盤となる Compute Engine 永続ディスク ハンドラを見つけます。

      kubectl get pv/$PV_NAME -o json | jq -r .spec.csi.volumeHandle

    次のように置き換えます。

    • PV_NAME: 前の手順のレスポンスから取得したバックアップ ディスクの PV 名。

    レスポンスの例を次に示します。

      projects/my-project/zones/us-central1-a/disks/pvc-89f91fba-6cd2-4bfa-84ed-cb5969b446c3

  4. バックアップ ディスク名を、次のセクションで使用する変数としてエクスポートします。

      export BACKUP_DISK=pvc-89f91fba-6cd2-4bfa-84ed-cb5969b446c3

バックアップ ディスクをターゲット サーバーにマウントする

ターゲット サーバーが Compute Engine 仮想マシンにインストールされている AlloyDB Omni サーバーであると想定して、バックアップ ディスクをサーバーにマウントします。

  1. gcloud compute instances attach-disk コマンドを実行してディスクをマウントします。

      gcloud compute instances attach-disk GCE_INSTANCE_NAME \
  --disk ${BACKUP_DISK} \
  --zone=$GCE_ZONE

    次のように置き換えます。

    • GCE_INSTANCE_NAME: Compute Engine 仮想マシンにターゲット サーバーがインストールされているインスタンスの名前。

    • GCE_ZONE: Compute Engine 仮想マシン インスタンスが存在するゾーン。

  2. バックアップ ディスクをターゲット サーバーにマウントします。

       lsblk
   mkdir -p /mnt/disks/backupdisk
   mount -o discard,defaults /dev/sdb /mnt/disks/backupdisk

  3. /var/alloydb/config ディレクトリの AlloyDB Omni dataplane.conf ファイルにカスタム バインディング マウントを追加します。

      PG_BIND_MOUNTS=/mnt/disks/backupdisk:/mnt/disks/backups:rshared

Docker でのバインディング マウントの詳細については、バインディング マウントをご覧ください。

  1. ターゲット サーバーを再起動します。

Docker

  docker restart CONTAINER_NAME

CONTAINER_NAME は、新しい AlloyDB Omni コンテナの名前に置き換えます（my-omni-1 など）。

Podman 

  podman restart CONTAINER_NAME

CONTAINER_NAME は、新しい AlloyDB Omni コンテナの名前に置き換えます（my-omni-1 など）。

pgBackRest 構成ファイルを更新する

バックアップ ディスク ディレクトリの既存の pgBackRest ファイルを、新しいリポジトリパスで更新します。

  1. ターゲット サーバーで、/mnt/disks/backupdisk ディレクトリに移動します。

      cd /mnt/disks/backupdisk

  2. 既存のデータを上書きしないように、pgbackrest.conf ファイルで pg1-path パスを一時ディレクトリに更新します。data-restored ディレクトリは、復元プロセスの一部として自動的に作成されます。

      sudo sed -i 's|.*pg1-path.*|pg1-path=/mnt/disks/pgsql/data-restored|' pgbackrest.conf

  3. pgbackrest.conf ファイルで、一時ディレクトリへの repo1-path パスを更新します。

      sudo sed -i 's|.*repo1-path.*|repo1-path=/mnt/disks/backups/repo|' conf.d/repo1-local-backupplan.conf

ターゲット データベース クラスタのソース バックアップを確認する

ターゲット サーバーにログインし、pgBackRest コマンドを実行して、ターゲット サーバーでソース データベース クラスタのバックアップにアクセスできることを確認します。

Docker

  sudo docker exec CONTAINER_NAME pgbackrest --config-path=/mnt/disks/backups --stanza=db --repo=1 info

Podman 

  sudo podman exec CONTAINER_NAME pgbackrest --config-path=/mnt/disks/backups --stanza=db --repo=1 info

レスポンスの例を次に示します。

    stanza: db
    status: ok
    cipher: none
    db (current)
        wal archive min/max (15): 000000010000000000000002/00000001000000000000000D
        full backup: 20240213-231400F
            timestamp start/stop: 2024-02-13 23:14:00+00 / 2024-02-13 23:17:14+00
            wal start/stop: 000000010000000000000003 / 000000010000000000000003
            database size: 38.7MB, database backup size: 38.7MB
            repo1: backup set size: 4.6MB, backup size: 4.6MB
        incr backup: 20240213-231400F_20240214-000001I
            timestamp start/stop: 2024-02-14 00:00:01+00 / 2024-02-14 00:00:05+00
            wal start/stop: 00000001000000000000000D / 00000001000000000000000D
            database size: 38.7MB, database backup size: 488.3KB
            repo1: backup set size: 4.6MB, backup size: 84.2KB
            backup reference list: 20240213-231400F

レスポンスのタイムスタンプは、完全バックアップの復元または復元ウィンドウ内の特定の時点からの復元に使用されます。

ターゲット サーバーでバックアップを復元する

復元するバックアップまたは復元ポイントを特定したら、ターゲット サーバーで pgBackRest コマンドを実行します。これらのコマンドの詳細については、復元コマンドをご覧ください。

pgBackRest 復元コマンドの例を以下に示します。

  • バックアップからの復元

    pgbackrest --config-path=/mnt/disks/backups --stanza=db --repo=1 restore --set=20240213-231400F --type=immediate --target-action=promote --delta --link-all --log-level-console=info

  • 特定の時点からの復元

    pgbackrest --config-path=/mnt/disks/backups --stanza=db --repo=1 restore --target="2024-01-22 11:27:22" --type=time --target-action=promote --delta --link-all --log-level-console=info

ターゲット サーバーにデータをコピーする

復元コマンドが正常に完了したら、data-restored 一時ディレクトリから現在の AlloyDB データ ディレクトリにデータをコピーできます。

  1. ターゲット サーバーで、データベース サービスを停止します。

    Docker

    docker stop CONTAINER_NAME

    Podman 

    podman stop CONTAINER_NAME

  2. ベスト プラクティスとして、現在のデータ ディレクトリの名前を別の名前に変更します。

      mv ~/alloydb-data/data  ~/alloydb-data/data-old

  3. data-restored 一時ディレクトリの名前を現在のデータ ディレクトリに変更します。

      mv ~/alloydb-data/data-restored ~/alloydb-data/data

  4. postgresql.auto.conf ファイルの pg1-path 値を更新して、復元されたデータを読み込みます。

        vim ~/alloydb-data/data/postgresql.auto.conf
    # Verify postgresql.auto.conf.
    # Do not edit this file manually!
    # It will be overwritten by the ALTER SYSTEM command.
    # Recovery settings generated by pgBackRest restore on 2024-03-13 20:47:11
    restore_command = 'pgbackrest --config-path=/mnt/disks/pgsql --pg1-path=/mnt/disks/pgsql/data --repo=1 --stanza=db archive-get %f "%p"'
    recovery_target = 'immediate'
    recovery_target_action = 'promote'
    recovery_target_timeline = 'current'

  5. ターゲット サーバーでデータベース サービスを起動します。

    Docker

    docker start CONTAINER_NAME

    Podman 

    podman start CONTAINER_NAME

データベース サービスが起動したら、プライマリ インスタンスに接続してクエリを実行し、バックアップからデータが復元されたことを確認できます。詳細については、単一サーバーの AlloyDB Omni に接続するをご覧ください。

次のステップ