This page shows you how to clone a database cluster in Kubernetes using a Cloud Storage backup of an AlloyDB Omni database cluster.
The following workflow explains the steps used to clone:
- Create and apply the
DBCluster
manifest file on the target database cluster with thelivenessProbe
parameter disabled. - Create and configure the
pgbackrest.conf
file to access the Cloud Storage backup. - Use
pgBackRest
commands to verify you can access source backups. - Use
pgBackRest
commands to restore the backup to the target database cluster.
Before you begin
- Make sure you have access to the full path of the Cloud Storage bucket
where your source database cluster backup is stored. This is the same path you
used when you created the
BackupPlan
resource for your source database cluster. - Create a target AlloyDB Omni database cluster. For more information about installing AlloyDB Omni on Kubernetes, see Create a database cluster.
- Ensure you are logged in to the database as the
postgres
user.
Create a database cluster in a target database cluster
Create a database cluster by temporarily disabling the livenessProbe
parameter. After the restore finishes, reconfigure the livenessProbe
parameter.
Create the
DBCluster
resource manifest file: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
Replace the following:
DB_CLUSTER_NAME
: the name of this database cluster—for example,my-db-cluster
.ENCODED_PASSWORD
: the database login password for the defaultpostgres
user role, encoded as a base64 string—for example,Q2hhbmdlTWUxMjM=
forChangeMe123
.CPU_COUNT
: the number of CPUs available to each database instance in this database cluster.MEMORY_SIZE
: the amount of memory per database instance of this database cluster. We recommend setting this to 8 gigabytes per CPU. For example, if you setcpu
to2
earlier in this manifest, then we recommend settingmemory
to16Gi
.DISK_SIZE
: the disk size per database instance—for example,10Gi
.
Apply the manifest file:
kubectl apply -f DBCLUSTER_FILENAME
Replace the following:
- DBCLUSTER_FILENAME: the name of the
DBCluster
manifest file created in the previous step.
- DBCLUSTER_FILENAME: the name of the
Use the kubectl describe
command to verify that the database cluster resource
is in the READY
status.
Configure the pgBackRest
file
Configure the pgBackRest
file to enable the target database cluster to access
the Cloud Storage bucket where source backups reside.
In your target database cluster, find the database cluster pod details:
kubectl get pod -l "alloydbomni.internal.dbadmin.goog/dbcluster=<var>DB_CLUSTER_NAME</var>, alloydbomni.internal.dbadmin.goog/task-type=database"
The response includes the name of the cluster database pod.
Log into the pod:
kubectl exec -ti DATABASE_POD_NAME -- /bin/bash
Replace the following:
- DATABASE_POD_NAME: the name of the database cluster pod from the previous step.
Stop the pod before updating the
pgBackRest
configuration file:supervisorctl.par stop postgres
Create a
pgBackRest
configuration file to access backups stored in Cloud Storage: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
Replace the following:
GCS_SOURCE_BACKUP_BUCKET_NAME
: the name of the Cloud Storage bucket that you created when creating theBackupPlan
resource manifest file for the source database cluster. This is not the full URL to the bucket; don't prefix the bucket name withgs://
.GCS_SOURCE_BACKUP_BUCKET_PATH
: the path of the directory that the AlloyDB Omni Operator writes backups into, within the Cloud Storage bucket for the source database cluster. The path must be absolute, beginning with/
.
The
repo1-gcs-key-type
is set toauto
to use the instance's service account. For more information about other options, see GCS Repository Key Type Option.
Verify source backups in the target database cluster
Run pgBackRest
commands to verify that the source database cluster backups are
accessible on the target database cluster.
pgbackrest --config-path=/backup --stanza=db --repo=1 info
The following is a sample response:
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
The timestamps in the response are used either to restore the full backup or to restore from a point in time from the recovery window.
Restore the backup in the target database cluster
After you identify the backup or a point in time you want to restore to, run
pgBackRest
commands in your target database cluster. For more information
about these commands, see Restore
Command.
The following are some sample pgBackRest
restore commands:
Restore from a backup
pgbackrest --config-path=/backup --stanza=db --repo=1 restore --set=20240213-231400F --type=immediate --target-action=promote --delta --link-all --log-level-console=info
Restore from a point in time
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
Restart the pod
After the restore command completes successfully, you can start the postgres
process.
supervisorctl.par start postgres
After the postgres
process starts, you can connect to the primary instance and
run queries to verify that the data is restored from the backup. For more
information, see Connect to AlloyDB Omni running on
Kubernetes.
Configure the database cluster
After you clone a database cluster, configure your database cluster specifications. Most importantly, don't forget to turn on the livenessProbe
parameter with the following command:
kubectl patch dbcluster DBCLUSTER_FILENAME --type merge -p '{"spec":{"primarySpec":{"availabilityOptions":{"livenessProbe":"Enabled"}}}}'