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

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

このページの手順では、ソース データベース クラスタとターゲット データベース クラスタが Google Kubernetes Engine で作成され、バックアップ ディスクが Compute Engine 永続ディスクであることを前提としています。また、データベースのバックアップとして使用される Compute Engine 永続ディスクが、他のどのデータベース クラスタでも使用されていないことを前提としています。

次のワークフローは、クローン作成に使用される手順を示しています。

  1. ソース データベース クラスタのバックアップ ディスクのバックアップ ディスク情報（永続ボリューム名、Compute Engine 永続ディスク ハンドラなど）を特定します。
  2. PersistentVolume リソースを作成して、ターゲット データベース クラスタの既存のバックアップ ディスクを使用して、ソース データベース クラスタのバックアップ ディスクにアクセスします。
  3. livenessProbe パラメータを無効にしてバックアップ ディスク情報を追加し、移行先のデータベース クラスタに DBCluster リソース マニフェスト ファイルを作成して適用します。
  4. pgBackRest コマンドを使用して、ソース バックアップにアクセスできることを確認します。
  5. pgBackRest コマンドを使用して、バックアップをターゲット データベース クラスタに復元します。

始める前に

  • 移行元データベース クラスタのバックアップが保存されているバックアップ ディスクにアクセスできることを確認します。
  • ソース データベース クラスタのバックアップ ディスクをターゲット データベース クラスタにマウントできる必要があります。ディスクがマウント可能になるようにする手順の詳細については、永続ボリュームをご覧ください。
  • ソース バックアップ ディスクはターゲット データベース クラスタにマウントされているため、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 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 名。

ターゲット データベース クラスタに永続ボリューム リソースを作成する

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

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

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

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

      kubectl apply -f PV_FILENAME

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

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

移行先データベース クラスタを作成する

復元プロセスが完了するまで 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:
    primarySpec:
      availabilityOptions:
        livenessProbe: "Disabled"
      adminUser:
        passwordRef:
          name: db-pw-DB_CLUSTER_NAME
      resources:
        memory: 100Gi
        cpu: 10
        disks:
        - name: DataDisk
          size: 40Gi
        - name: BackupDisk
          size: ${DISK_SIZE}
          storageClass: ${STORAGE_CLASS}
          volumeName: backupdisk

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

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

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

  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 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 に接続するをご覧ください。

次のステップ