使用本地备份在 Kubernetes 中克隆数据库集群

本页介绍了如何使用 AlloyDB Omni 数据库集群的本地备份在 Kubernetes 中克隆数据库集群。

本页中的步骤假定您的源数据库集群和目标数据库集群是在 Google Kubernetes Engine 上创建的，并且备份磁盘是 Compute Engine 永久性磁盘。它还假定在数据库中用作备份的 Compute Engine 永久性磁盘未被任何其他数据库集群使用。

以下工作流程介绍了克隆所用步骤：

  1. 确定源数据库集群备份磁盘的备份磁盘信息，例如永久性卷名称和 Compute Engine 永久性磁盘句柄。
  2. 创建 PersistentVolume 资源，以使用目标数据库集群上的现有备份磁盘访问源数据库集群的备份磁盘。
  3. 在目标数据库集群上创建并应用 DBCluster 资源清单文件，并停用 livenessProbe 参数并添加备份磁盘信息。
  4. 使用 pgBackRest 命令验证是否可以访问源备份。
  5. 使用 pgBackRest 命令将备份恢复到目标数据库集群。

准备工作

  • 确保您有权访问存储源数据库集群备份的备份磁盘。
  • 源数据库集群备份磁盘必须能够挂载到目标数据库集群。如需详细了解确保磁盘可挂载的步骤，请参阅永久性卷。
  • 由于源备份磁盘已挂载到目标数据库集群，因此 pgBackRest.conf 文件会按原样重复使用。
  • 确保您已以 postgres 用户身份登录数据库。

获取来源备份磁盘信息

在恢复过程中，请确定源数据库集群的备份磁盘永久性卷声明 (PVC) 名称。PVC 在 Kubernetes 中用于管理应用的永久性存储空间。

以下示例命令可帮助您找到底层 PV 名称和 Compute Engine 永久性磁盘处理程序。在此示例中，所有备份磁盘都是 Compute Engine 永久性磁盘，可通过磁盘处理程序标识符在 Compute Engine 虚拟机之间访问。

  1. 连接到目标数据库集群以查找 PVC 名称：

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

    替换以下内容：

    • DB_CLUSTER_NAMESPACE：此备份方案的 Kubernetes 命名空间。它必须与数据库集群的命名空间一致。

    • 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. 请先停止 pod，然后再更新 pgBackRest 配置文件：

      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。

后续步骤