Cloud Storage バックアップを使用して Kubernetes でデータベース クラスタをクローン化する

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

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

  1. livenessProbe パラメータを無効にして、移行先データベース クラスタに DBCluster マニフェスト ファイルを作成して適用します。
  2. Cloud Storage バックアップにアクセスするための pgbackrest.conf ファイルを作成して構成します。
  3. pgBackRest コマンドを使用して、ソース バックアップにアクセスできることを確認します。
  4. pgBackRest コマンドを使用して、バックアップをターゲット データベース クラスタに復元します。

始める前に

  • ソース データベース クラスタのバックアップが保存されている Cloud Storage バケットの完全パスにアクセスできることを確認します。これは、ソース データベース クラスタの BackupPlan リソースの作成時に使用したパスと同じです。
  • 移行先の AlloyDB Omni データベース クラスタを作成します。Kubernetes への AlloyDB Omni のインストールの詳細については、データベース クラスタを作成するをご覧ください。
  • postgres ユーザーとしてデータベースにログインしていることを確認します。

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

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:
        primarySpec:
          availabilityOptions:
            livenessProbe: "Disabled"
          adminUser:
            passwordRef:
              name: db-pw-DB_CLUSTER_NAME
          resources:
            cpu: CPU_COUNT
            memory: MEMORY_SIZE
            disks:
            - name: DataDisk
              size: DISK_SIZE
              storageClass: standard
    

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

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

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

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

    • MEMORY_SIZE: このデータベース クラスタのデータベース インスタンスあたりのメモリ量。CPU あたり 8 ギガバイトに設定することをおすすめします。たとえば、このマニフェストの前半で cpu2 に設定した場合は、memory16Gi に設定することをおすすめします。

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

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

      kubectl apply -f DBCLUSTER_FILENAME

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

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

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

pgBackRest ファイルを構成する

ターゲット データベース クラスタがソース バックアップが存在する Cloud Storage バケットにアクセスできるように、pgBackRest ファイルを構成します。

  1. 移行先データベース クラスタで、データベース クラスタ Pod の詳細を確認します。

      kubectl get pod -l "alloydbomni.internal.dbadmin.goog/dbcluster=<var>DB_CLUSTER_NAME</var>, 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. Cloud Storage に保存されているバックアップにアクセスするための pgBackRest 構成ファイルを作成します。

      cat << EOF > /backup/pgbackrest.conf
      [db]
      pg1-path=/mnt/disks/pgsql/data
      pg1-socket-path=/tmp
      pg1-user=pgbackrest
      [global]
      log-path=/obs/pgbackrest
      log-level-file=info
      repo1-type=gcs
      repo1-gcs-bucket=GCS_SOURCE_BACKUP_BUCKET_NAME
      repo1-path=GCS_SOURCE_BACKUP_BUCKET_PATH
      repo1-storage-ca-file=/etc/ssl/certs/ca-certificates.crt
      repo1-retention-full=9999999
      repo1-gcs-key-type=auto

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

    • GCS_SOURCE_BACKUP_BUCKET_NAME: ソース データベース クラスタの BackupPlan リソース マニフェスト ファイルを作成したときに作成した Cloud Storage バケットの名前。これはバケットの完全な URL ではありません。バケット名の前に gs:// を付けないでください。
    • GCS_SOURCE_BACKUP_BUCKET_PATH: AlloyDB Omni オペレーターがバックアップを書き込むディレクトリのパス(ソース データベース クラスタの Cloud Storage バケット内)。パスは絶対パスで、/ で始まる必要があります。

    repo1-gcs-key-type は、インスタンスのサービス アカウントを使用するように auto に設定されています。他のオプションの詳細については、GCS リポジトリ キータイプのオプションをご覧ください。

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

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

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"}}}}'

次のステップ