本文档介绍了如何使用 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.0" 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 的名称。
请先停止 pod，然后再更新
pgBackRest配置文件：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"}}}}'