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

このドキュメントでは、AlloyDB Omni データベース クラスタのローカル バックアップを使用して Kubernetes でデータベース クラスタのクローンを作成する方法について説明します。

このドキュメントでは、次のことを前提としています。

  • ソース データベース クラスタとターゲット データベース クラスタが Google Kubernetes Engine に作成されていて、バックアップ ディスクが Compute Engine 永続ディスクである。
  • データベースのバックアップ ディスクとして使用される Compute Engine 永続ディスクが、他のデータベース クラスタでは使用されていない。

データベース クラスタのクローンを作成する手順は次のとおりです。

  1. ソース データベース クラスタのバックアップ ディスクのバックアップ ディスク情報（永続ボリューム名、Compute Engine 永続ディスク ハンドラなど）を特定します。ソース データベース クラスタのバックアップ機能が有効になっていることと、少なくとも 1 つのバックアップが正常に完了していることを確認します。これらの条件を満たしていない場合は、バックアップを有効にしてスケジュールを設定するの手順を実施します。
  2. PersistentVolume リソースを作成して、ターゲット データベース クラスタの既存のバックアップ ディスクを使用し、ソース データベース クラスタのバックアップ ディスクにアクセスします。
  3. livenessProbe パラメータを無効にしてバックアップ ディスク情報を追加し、ターゲット データベース クラスタに DBCluster リソース マニフェスト ファイルを作成して適用します。
  4. pgBackRest コマンドを使用して、ソース バックアップにアクセスできることを確認します。
  5. pgBackRest コマンドを使用して、バックアップをターゲット データベース クラスタに復元します。

始める前に

  • ソース データベース クラスタのバックアップが保存されているバックアップ ディスクにアクセスできることを確認します。
  • ソース データベース クラスタのバックアップ ディスクをターゲット データベース クラスタにマウントできる必要があります。詳細については、永続ボリュームをご覧ください。基盤となるストレージ バックエンドが ReadOnlyMany（ROX）アクセスをサポートしていない場合は、バックアップ ディスクがソースクラスタ内の Pod で使用されていないことを確認します。
  • ソース バックアップ ディスクはターゲット データベース クラスタにマウントされているため、pgBackRest.conf ファイルはそのまま再利用されます。
  • postgres ユーザーとしてデータベースにログインしていることを確認します。

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

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

次のサンプル コマンドを使用すると、基盤となる PV 名と Compute Engine 永続ディスク ハンドラを見つけることができます。この例では、すべてのバックアップ ディスクは Compute Engine 永続ディスクであり、ディスク ハンドラ ID を使用して Compute Engine VM 間でアクセスできます。

  1. ターゲット データベース クラスタに接続して、PVC 名を確認します。

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

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

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

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

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

        backuprepodisk-my-db-cluster-br-0   Bound
    pvc-36d8f05d-ef1a-4750-ac01-9bb330c15b3a   10Gi       RWO            standard-rwo   5d21h

  2. 前の手順のバックアップ ディスク PVC 名（backuprepodisk-my-db-cluster-br-0 など）を使用して、基盤となる PV 名と Compute Engine 永続ディスク ハンドラを見つけます。

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

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

    • PVC_NAME: 前の手順のレスポンスから取得したバックアップ ディスクの PVC 名（例: backuprepodisk-my-db-cluster-br-0）。

  3. PV 名に基づいて構成を変数としてエクスポートし、後続のセクションで使用します。

      export BACKUP_DISK_SIZE=$(kubectl get pv/PV_NAME -o jsonpath="{.spec.capacity.storage}")
  export FS_TYPE=$(kubectl get pv/PV_NAME -o jsonpath="{.spec.csi.fsType}")
  export VOLUME_HANDLER=$(kubectl get pv/PV_NAME -o jsonpath="{.spec.csi.volumeHandle}")
  export STORAGE_CLASS=$(kubectl get pv/PV_NAME -o jsonpath="{.spec.storageClassName}")

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

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

永続ボリューム リソースを作成する

ディスク ハンドラ名を使用して、PersistentVolume リソースを作成します。

  1. ターゲット Kubernetes クラスタで、PersistentVolume マニフェスト ファイルを作成します。

        apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: PV_NAME
    spec:
      storageClassName: "${STORAGE_CLASS}"
      capacity:
        storage: "${BACKUP_DISK_SIZE}"
      accessModes:
        - ReadWriteOnce
      csi:
        driver: pd.csi.storage.gke.io
        volumeHandle: "${VOLUME_HANDLER}"
        fsType: "${FS_TYPE}"

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

    • PV_NAME: 作成される PersistentVolume リソースの名前。

  2. マニフェスト ファイルを適用します。

      kubectl apply -f PV_FILENAME

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

    • PV_FILENAME: 前の手順で作成した PersistentVolume マニフェスト ファイルの名前。

ターゲット データベース クラスタを作成する

livenessProbe パラメータを一時的に無効にして、データベース クラスタを作成します。復元が完了したら、livenessProbe パラメータを再構成します。

  1. DBCluster マニフェスト ファイルを作成します。

      apiVersion: v1
  kind: Secret
  metadata:
    name: db-pw-DB_CLUSTER_NAME
  type: Opaque
  data:
    DB_CLUSTER_NAME: "ENCODED_PASSWORD"
  ---
  apiVersion: alloydbomni.dbadmin.goog/v1
  kind: DBCluster
  metadata:
    name: DB_CLUSTER_NAME
  spec:
    databaseVersion: "15.7.1"
    primarySpec:
      availabilityOptions:
        livenessProbe: "Disabled"
      adminUser:
        passwordRef:
          name: db-pw-DB_CLUSTER_NAME
      resources:
        cpu: CPU_COUNT
        memory: MEMORY_SIZE
        disks:
        - name: DataDisk
          size: DATA_DISK_SIZE
        - name: BackupDisk
          size: ${BACKUP_DISK_SIZE}
          storageClass: ${STORAGE_CLASS}
          volumeName: PV_NAME

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

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

    • ENCODED_PASSWORD: デフォルトの postgres ユーザー ロールのデータベース ログイン パスワード。base64 文字列としてエンコードされます。例: ChangeMe123 の場合は Q2hhbmdlTWUxMjM=

    • CPU_COUNT: このデータベース クラスタ内の各データベース インスタンスで使用できる CPU の数。

    • MEMORY_SIZE: このデータベース クラスタのデータベース インスタンスあたりのメモリ量。CPU あたり 8 GB に設定することをおすすめします。たとえば、CPU_COUNT を 2 に設定する場合は、memory を 16Gi に設定することをおすすめします。

    • DATA_DISK_SIZE: データベース インスタンスあたりのディスクサイズ。例: 10Gi

  2. マニフェスト ファイルを適用します。

      kubectl apply -f DBCLUSTER_FILENAME

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

    • DBCLUSTER_FILENAME: 前の手順で作成した DBCluster マニフェスト ファイルの名前。

kubectl describe コマンドを使用して、データベース クラスタ リソースが READY ステータスであることを確認します。

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

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

  1. ターゲット データベース クラスタで、データベース クラスタ Pod の詳細を確認します。

      kubectl get pod -l "alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME, alloydbomni.internal.dbadmin.goog/task-type=database"

    レスポンスには、クラスタ データベース Pod の名前が含まれます。

  2. データベース Pod にログインします。

      kubectl exec -ti DATABASE_POD_NAME  -- /bin/bash

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

    • DATABASE_POD_NAME: 前の手順で作成したデータベース クラスタ Pod の名前。

  3. pgBackRest 構成ファイルを更新する前に、Pod を停止します。

      supervisorctl.par stop postgres

  4. pgBackRest 構成ファイルを更新します。

      cp /backup/pgbackrest.conf /backup/pgbackrest.conf.bak
  rm /backup/pgbackrest.conf
  cat << EOF > /backup/pgbackrest.conf
  [db]
  pg1-path=/mnt/disks/pgsql/data
  pg1-socket-path=/tmp
  pg1-user=pgbackrest
  [global]
  log-path=/backup/logs
  log-level-file=info
  EOF

  5. データベース クラスタ Pod でソース バックアップを確認します。

    pgbackrest --config-path=/backup --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=/backup --stanza=db --repo=1 restore --set=20240213-231400F --type=immediate --target-action=promote --delta --link-all --log-level-console=info

  • 特定の時点から復元する

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

Pod を再起動する

復元コマンドが正常に完了したら、postgres プロセスを開始できます。

supervisorctl.par start postgres

postgres プロセスが開始したら、プライマリ インスタンスに接続してクエリを実行し、データがバックアップから復元されたことを確認できます。詳細については、Kubernetes で実行されている AlloyDB Omni に接続するをご覧ください。

データベース クラスタを構成する

データベース クラスタのクローンを作成したら、データベース クラスタの仕様を構成します。次のコマンドを使用して、livenessProbe パラメータをオンにしてください。

    kubectl patch dbcluster DBCLUSTER_FILENAME --type merge -p '{"spec":{"primarySpec":{"availabilityOptions":{"livenessProbe":"Enabled"}}}}'

次のステップ