本文档介绍了如何使用 AlloyDB Omni 数据库集群的本地备份在 Kubernetes 中克隆数据库集群。
本文档假定存在以下情况：
- 来源数据库集群和目标数据库集群是在 Google Kubernetes Engine 上创建的，而备份磁盘是 Compute Engine 永久性磁盘。
- 在数据库中用作备份磁盘的 Compute Engine 永久性磁盘未被其他数据库集群使用。
克隆数据库集群时，请按照以下步骤操作：
- 确定备份磁盘信息，例如来源数据库集群备份磁盘的永久性卷名称和 Compute Engine 永久性磁盘处理程序。确保您为来源数据库集群启用了备份功能，并且至少有一个成功的备份。如果不满足这些条件，请按照启用和安排备份中的说明操作。
- 创建
PersistentVolume资源，以使用目标数据库集群上的现有备份磁盘来访问来源数据库集群的备份磁盘。 - 在目标数据库集群上创建并应用
DBCluster资源清单文件，在其中停用livenessProbe参数并添加备份磁盘信息。 - 使用
pgBackRest命令验证是否可以访问来源备份。 - 使用
pgBackRest命令将备份恢复到目标数据库集群。
准备工作
- 确保您有权访问存储来源数据库集群备份的备份磁盘。
- 来源数据库集群备份磁盘必须能够装载到目标数据库集群。如需了解详情，请参阅永久性卷。如果底层存储后端不支持 ReadOnlyMany (ROX) 访问，请确保备份磁盘未被来源集群中的任何 Pod 使用。
- 由于来源备份磁盘会装载到目标数据库集群，因此
pgBackRest.conf文件会按原样重复使用。 - 确保您以
postgres用户身份登录数据库。
获取来源备份磁盘信息
在恢复过程中，确定来源数据库集群的备份磁盘永久性卷声明 (PVC) 名称。PVC 在 Kubernetes 中用于为应用管理永久性存储。
以下示例命令可帮助您找到底层 PV 名称和 Compute Engine 永久性磁盘处理程序。在此示例中，所有备份磁盘都是 Compute Engine 永久性磁盘，可以使用磁盘处理程序标识符跨 Compute Engine 虚拟机进行访问。
连接到目标数据库集群以查找 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使用上一步中的备份磁盘 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。
根据 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 资源。
在目标 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资源的名称。
- PV_NAME：要创建的
应用清单文件：
kubectl apply -f PV_FILENAME替换以下内容：
- PV_FILENAME：在上一步中创建的
PersistentVolume清单文件的名称。
- PV_FILENAME：在上一步中创建的
创建目标数据库集群
通过暂时停用 livenessProbe 参数来创建数据库集群。恢复完成后，重新配置 livenessProbe 参数。
创建
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 千兆字节。例如，如果您将 CPU_COUNT 设置为2，则建议将memory设置为16Gi。DATA_DISK_SIZE：每个数据库实例的磁盘大小，例如10Gi。
应用清单文件：
kubectl apply -f DBCLUSTER_FILENAME替换以下内容：
- DBCLUSTER_FILENAME：在上一步中创建的
DBCluster清单文件的名称。
- DBCLUSTER_FILENAME：在上一步中创建的
使用 kubectl describe 命令验证数据库集群资源是否处于 READY 状态。
验证目标数据库集群中的来源备份
运行 pgBackRest 命令，验证是否可以在目标数据库集群上访问来源数据库集群备份。
在目标数据库集群中，查找数据库集群 Pod 详细信息：
kubectl get pod -l "alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME, alloydbomni.internal.dbadmin.goog/task-type=database"响应包括集群数据库 Pod 的名称。
登录数据库 Pod：
kubectl exec -ti DATABASE_POD_NAME -- /bin/bash替换以下内容：
- DATABASE_POD_NAME：上一步中的数据库集群 Pod 的名称。
在更新
pgBackRest配置文件之前，请先停止 Pod：supervisorctl.par stop postgres更新
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验证数据库集群 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 postgrespostgres 进程启动后，您可以连接到主实例并运行查询，以验证数据是否已从备份恢复。如需了解详情，请参阅连接到 Kubernetes 上运行的 AlloyDB Omni。
配置数据库集群
克隆数据库集群后，请配置数据库集群规范。请务必使用以下命令启用 livenessProbe 参数：
kubectl patch dbcluster DBCLUSTER_FILENAME --type merge -p '{"spec":{"primarySpec":{"availabilityOptions":{"livenessProbe":"Enabled"}}}}'