En esta página, se muestra cómo clonar un clúster de bases de datos en Kubernetes con la copia de seguridad local de un clúster de bases de datos de AlloyDB Omni.
En los pasos de esta página, se supone que los clústeres de bases de datos de origen y destino se crean en Google Kubernetes Engine, y que los discos de copia de seguridad son discos persistentes de Compute Engine. También se supone que ningún otro clúster de base de datos usa los discos persistentes de Compute Engine que se usan como copia de seguridad en la base de datos.
En el siguiente flujo de trabajo, se explican los pasos que se usan para clonar lo siguiente:
- Identifica la información del disco de copia de seguridad, como el nombre del volumen persistente y el controlador de disco persistente de Compute Engine, para el disco de copia de seguridad del clúster de la base de datos de origen.
- Crea un recurso
PersistentVolume
para usar un disco de copia de seguridad existente en el clúster de base de datos de destino para acceder al disco de copia de seguridad del clúster de base de datos de origen. - Crea y aplica el archivo de manifiesto de recursos
DBCluster
en el clúster de bases de datos de destino con el parámetrolivenessProbe
inhabilitado y la información del disco de copia de seguridad agregada. - Usa los comandos
pgBackRest
para verificar que se pueda acceder a las copias de seguridad de origen. - Usa los comandos
pgBackRest
para restablecer la copia de seguridad en el clúster de base de datos de destino.
Antes de comenzar
- Asegúrate de tener acceso al disco de copia de seguridad en el que se almacena la copia de seguridad del clúster de la base de datos de origen.
- El disco de copia de seguridad del clúster de la base de datos de origen debe poder activarse en el clúster de la base de datos de destino. Para obtener más información sobre los pasos para garantizar que el disco se pueda activar, consulta Volúmenes persistentes.
- Dado que el disco de copia de seguridad de origen está activado en el clúster de base de datos de destino, el archivo
pgBackRest.conf
se reutiliza tal como está. - Asegúrate de haber accedido a la base de datos como el usuario
postgres
.
Obtén información del disco de copia de seguridad de origen
Como parte del proceso de restablecimiento, determina el nombre de la reclamación de volumen persistente (PVC) del disco de copia de seguridad para tu clúster de base de datos de origen. Los PVC se usan en Kubernetes para administrar el almacenamiento persistente de las aplicaciones.
Los siguientes comandos de muestra ayudan a ubicar el nombre de PV subyacente y el controlador de disco persistente de Compute Engine. En el ejemplo, todos los discos de copia de seguridad son discos persistentes de Compute Engine, a los que se puede acceder en las VMs de Compute Engine con el identificador del controlador de disco.
Conéctate al clúster de base de datos de destino para encontrar el nombre del PVC:
kubectl get pvc -n DB_CLUSTER_NAMESPACE | grep DB_CLUSTER_NAME | grep backuprepodisk
Reemplaza lo siguiente:
DB_CLUSTER_NAMESPACE
: El espacio de nombres de Kubernetes para este plan de copia de seguridad. Debe coincidir con el espacio de nombres del clúster de bases de datos.DB_CLUSTER_NAME
: Es el nombre de este clúster de bases de datos, por ejemplo,my-db-cluster
.
La siguiente es la respuesta de ejemplo.
backuprepodisk-my-db-cluster-br-0 Bound pvc-36d8f05d-ef1a-4750-ac01-9bb330c15b3a 10Gi RWO standard-rwo 5d21h
Usa el nombre del PVC del disco de copia de seguridad del paso anterior, por ejemplo,
backuprepodisk-my-db-cluster-br-0
, para encontrar el nombre de PV subyacente y el controlador de disco persistente de Compute Engine:kubectl get pvc/PVC_NAME -n DB_CLUSTER_NAMESPACE -o jsonpath={.spec.volumeName}
Reemplaza lo siguiente:
PVC_NAME
: El nombre de PVC del disco de copia de seguridad de la respuesta del paso anterior, por ejemplo,backuprepodisk-my-db-cluster-br-0
.
Exporta las configuraciones según el nombre del PV como variables que se usarán en las secciones posteriores:
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}")
Reemplaza lo siguiente:
PV_NAME
: Es el nombre del PV del disco de copia de seguridad de la respuesta del paso anterior.
Crea un recurso de volumen persistente en el clúster de la base de datos de destino
Con el nombre del controlador de disco, crea un recurso PersistentVolume
.
En el clúster de la base de datos de destino, crea el archivo de manifiesto
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}"
Aplica el archivo de manifiesto:
kubectl apply -f PV_FILENAME
Reemplaza lo siguiente:
- PV_FILENAME: Es el nombre del archivo de manifiesto
PersistentVolume
que se creó en el paso anterior.
- PV_FILENAME: Es el nombre del archivo de manifiesto
Crea un clúster de base de datos de destino
Para crear un clúster de bases de datos, inhabilita temporalmente el parámetro livenessProbe
mientras se completa el proceso de restablecimiento.
Crea el archivo de manifiesto
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
Reemplaza lo siguiente:
DB_CLUSTER_NAME
: Es el nombre de este clúster de bases de datos, por ejemplo,my-db-cluster
.ENCODED_PASSWORD
: Es la contraseña de acceso a la base de datos del rol de usuariopostgres
predeterminado, codificada como una cadena base64, por ejemplo,Q2hhbmdlTWUxMjM=
paraChangeMe123
.
Aplica el archivo de manifiesto:
kubectl apply -f DBCLUSTER_FILENAME
Reemplaza lo siguiente:
- DBCLUSTER_FILENAME: Es el nombre del archivo de manifiesto
DBCluster
que se creó en el paso anterior.
- DBCLUSTER_FILENAME: Es el nombre del archivo de manifiesto
Usa el comando kubectl describe
para verificar que el recurso del clúster de bases de datos esté en el estado READY
.
Verifica las copias de seguridad de origen en el clúster de la base de datos de destino
Ejecuta los comandos pgBackRest
para verificar que se pueda acceder a las copias de seguridad del clúster de la base de datos de origen en el clúster de la base de datos de destino.
En el clúster de base de datos de destino, busca los detalles del pod del clúster de base de datos:
kubectl get pod -l "alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME, alloydbomni.internal.dbadmin.goog/task-type=database"
La respuesta incluye el nombre del pod de la base de datos del clúster.
Accede al pod de la base de datos:
kubectl exec -ti DATABASE_POD_NAME -- /bin/bash
Reemplaza lo siguiente:
- DATABASE_POD_NAME : Es el nombre del pod del clúster de bases de datos del paso anterior.
Detén el pod antes de actualizar el archivo de configuración
pgBackRest
:supervisorctl.par stop postgres
Actualiza el archivo de configuración
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
Verifica las copias de seguridad de origen en el pod del clúster de la base de datos:
pgbackrest --config-path=/backup --stanza=db --repo=1 info
A continuación, se muestra una respuesta de ejemplo:
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
Las marcas de tiempo de la respuesta se usan para restablecer la copia de seguridad completa o para restablecer desde un momento determinado de la ventana de recuperación.
Restablece la copia de seguridad en el clúster de base de datos de destino
Después de identificar la copia de seguridad o el momento al que deseas restablecer, ejecuta los comandos pgBackRest
en el clúster de la base de datos de destino. Para obtener más información sobre estos comandos, consulta Comando de restablecimiento.
Los siguientes son algunos comandos de restablecimiento de pgBackRest
de ejemplo:
Restablecer copia de seguridad
pgbackrest --config-path=/backup --stanza=db --repo=1 restore --set=20240213-231400F --type=immediate --target-action=promote --delta --link-all --log-level-console=info
Restablecer desde un punto determinado
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
Reinicia el pod
Una vez que se complete correctamente el comando de restablecimiento, puedes iniciar el proceso postgres
.
supervisorctl.par start postgres
Después de que se inicie el proceso de postgres
, puedes conectarte a la instancia principal y ejecutar consultas para verificar que los datos se restablezcan desde la copia de seguridad. Para obtener más información, consulta Cómo conectarse a AlloyDB Omni que se ejecuta en Kubernetes.