Clonar un clúster de bases de datos en un solo servidor mediante una copia de seguridad local

Selecciona una versión de la documentación:

En esta página se explica cómo clonar un clúster de bases de datos en un solo servidor mediante una copia de seguridad local.

En los pasos de esta página se da por hecho que el clúster de base de datos de Kubernetes de origen se ha creado en Google Kubernetes Engine y que los discos de copia de seguridad son discos persistentes de Compute Engine. También se da por hecho que el servidor único de AlloyDB Omni de destino está instalado en una máquina virtual (VM) de Compute Engine.

Si utilizas otros entornos, consulta la documentación correspondiente para replicar estos pasos en tu entorno.

En el siguiente flujo de trabajo se explican los pasos para clonar:

  1. Identifica la información del disco de copia de seguridad, como el nombre del volumen persistente y el controlador del disco persistente de Compute Engine, del disco de copia de seguridad del clúster de la base de datos de origen.
  2. Monta el disco de copia de seguridad del clúster de la base de datos de origen en el servidor de destino.
  3. Usa los comandos pgBackRest para verificar que se puede acceder a las copias de seguridad de origen.
  4. Usa los comandos pgBackRest para restaurar la copia de seguridad en el clúster de bases de datos de destino.

Antes de empezar

  • 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.
  • Se crea un clúster de base de datos de AlloyDB Omni de un solo servidor de destino. Para obtener más información sobre cómo instalar AlloyDB Omni en Kubernetes, consulta Instalar AlloyDB Omni.
  • Asegúrate de haber iniciado sesión en la base de datos como usuario postgres.

Obtener información del disco de copia de seguridad de origen

Como parte del proceso de restauración, determina el nombre de la reclamación de volumen persistente (PVC) del disco de copia de seguridad de tu clúster de base de datos de origen. Los PVCs se usan en Kubernetes para gestionar el almacenamiento persistente de las aplicaciones.

Los siguientes comandos de ejemplo ayudan a determinar el nombre del PV subyacente y el controlador de Persistent Disk de Compute Engine mediante el nombre del PVC del disco de copia de seguridad.

  1. Conéctate al clúster de GKE en el que has creado el clúster de base de datos de origen de AlloyDB Omni:

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

    Haz los cambios siguientes:

    • DB_CLUSTER_NAMESPACE: el espacio de nombres de Kubernetes de esta copia de seguridad. Debe coincidir con el espacio de nombres del clúster de la base de datos.

    • DB_CLUSTER_NAME: el nombre de este clúster de base de datos. Por ejemplo, my-db-cluster.

    A continuación se muestra la respuesta de ejemplo.

      backupdisk-al-fe8c-dbcluster-sample-0   Bound
  pvc-36d8f05d-ef1a-4750-ac01-9bb330c15b3a   10Gi       RWO            standard-rwo   5d21h
  ```

  2. Usa el nombre del disco de copia de seguridad del paso anterior (por ejemplo, backupdisk-al-fe8c-dbcluster-sample-0) para encontrar el nombre del PV subyacente:

      kubectl get pvc/PVC_NAME -n DB_CLUSTER_NAMESPACE -o jsonpath={.spec.volumeName}

    Haz los cambios siguientes:

    • PVC_NAME: el nombre de PVC del disco de copia de seguridad de la respuesta del paso anterior, por ejemplo, backupdisk-al-fe8c-dbcluster-sample-0.

  3. Busca el controlador de Persistent Disk de Compute Engine subyacente:

      kubectl get pv/$PV_NAME -o json | jq -r .spec.csi.volumeHandle

    Haz los cambios siguientes:

    • PV_NAME: el nombre del volumen persistente del disco de copia de seguridad de la respuesta del paso anterior.

    A continuación se muestra la respuesta de ejemplo:

      projects/my-project/zones/us-central1-a/disks/pvc-89f91fba-6cd2-4bfa-84ed-cb5969b446c3

  4. Exporta el nombre del disco de copia de seguridad como una variable que se usará en las siguientes secciones:

      export BACKUP_DISK=pvc-89f91fba-6cd2-4bfa-84ed-cb5969b446c3

Monta el disco de copia de seguridad en el servidor de destino

Suponiendo que el servidor de destino es un servidor AlloyDB Omni instalado en una máquina virtual de Compute Engine, monta el disco de copia de seguridad en el servidor.

  1. Ejecuta el comando gcloud compute instances attach-disk para montar el disco:

      gcloud compute instances attach-disk GCE_INSTANCE_NAME \
  --disk ${BACKUP_DISK} \
  --zone=$GCE_ZONE

    Haz los cambios siguientes:

    • GCE_INSTANCE_NAME: el nombre de la instancia en la que está instalado el servidor de destino en la máquina virtual de Compute Engine.

    • GCE_ZONE: la zona en la que se encuentra tu instancia de máquina virtual de Compute Engine.

  2. Monta el disco de copia de seguridad en el servidor de destino:

       lsblk
   mkdir -p /mnt/disks/backupdisk
   mount -o discard,defaults /dev/sdb /mnt/disks/backupdisk

  3. Añade un montaje de enlace personalizado al archivo dataplane.conf de AlloyDB Omni en el directorio /var/alloydb/config:

      PG_BIND_MOUNTS=/mnt/disks/backupdisk:/mnt/disks/backups:rshared

Para obtener más información sobre los montajes de enlace en Docker, consulta Montajes de enlace.

  1. Reinicia el servidor de destino:

Docker 

  docker restart CONTAINER_NAME

Sustituye CONTAINER_NAME por el nombre de un nuevo contenedor de AlloyDB Omni. Por ejemplo, my-omni-1.

Podman 

  podman restart CONTAINER_NAME

Sustituye CONTAINER_NAME por el nombre de un nuevo contenedor de AlloyDB Omni. Por ejemplo, my-omni-1.

Actualizar el archivo de configuración pgBackRest

Actualiza el archivo pgBackRest del directorio del disco de copia de seguridad con la nueva ruta del repositorio.

  1. En el servidor de destino, ve al directorio /mnt/disks/backupdisk:

      cd /mnt/disks/backupdisk

  2. Actualiza la ruta pg1-path a un directorio temporal en el archivo pgbackrest.conf para evitar que se sobrescriban los datos. El directorio data-restored se crea automáticamente como parte del proceso de restauración:

      sudo sed -i 's|.*pg1-path.*|pg1-path=/mnt/disks/pgsql/data-restored|' pgbackrest.conf

  3. Actualiza la ruta repo1-path a un directorio temporal en el archivo pgbackrest.conf:

      sudo sed -i 's|.*repo1-path.*|repo1-path=/mnt/disks/backups/repo|' conf.d/repo1-local-backupplan.conf

Verificar las copias de seguridad de origen en el clúster de la base de datos de destino

Inicia sesión en el servidor de destino y ejecuta los comandos pgBackRest para verificar que se puede acceder a las copias de seguridad del clúster de la base de datos de origen en el servidor de destino:

Docker 

  sudo docker exec CONTAINER_NAME pgbackrest --config-path=/mnt/disks/backups --stanza=db --repo=1 info

Podman 

  sudo podman exec CONTAINER_NAME pgbackrest --config-path=/mnt/disks/backups --stanza=db --repo=1 info

A continuación se muestra un ejemplo de respuesta:

    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 restaurar la copia de seguridad completa o para restaurar desde un momento dado de la ventana de recuperación.

Restaurar la copia de seguridad en el servidor de destino

Una vez que hayas identificado la copia de seguridad o el punto en el tiempo al que quieras restaurar el servidor, ejecuta los comandos pgBackRest en el servidor de destino. Para obtener más información sobre estos comandos, consulta Comando Restore.

A continuación se muestran algunos ejemplos de comandos de restauración de pgBackRest:

  • Restaurar a partir de copia de seguridad

    pgbackrest --config-path=/mnt/disks/backups --stanza=db --repo=1 restore --set=20240213-231400F --type=immediate --target-action=promote --delta --link-all --log-level-console=info

  • Restaurar desde un momento dado

    pgbackrest --config-path=/mnt/disks/backups --stanza=db --repo=1 restore --target="2024-01-22 11:27:22" --type=time --target-action=promote --delta --link-all --log-level-console=info

Copiar datos en el servidor de destino

Una vez que se haya completado correctamente el comando de restauración, puedes copiar los datos del directorio temporal data-restored al directorio de datos de AlloyDB actual.

  1. En el servidor de destino, detén el servicio de base de datos:

    Docker 

    docker stop CONTAINER_NAME

    Podman 

    podman stop CONTAINER_NAME

  2. Como práctica recomendada, cambia el nombre del directorio de datos actual por otro:

      mv ~/alloydb-data/data  ~/alloydb-data/data-old

  3. Cambia el nombre del directorio temporal data-restored por el del directorio de datos actual:

      mv ~/alloydb-data/data-restored ~/alloydb-data/data

  4. Actualice el valor pg1-path en el archivo postgresql.auto.conf para cargar los datos restaurados:

        vim ~/alloydb-data/data/postgresql.auto.conf
    # Verify postgresql.auto.conf.
    # Do not edit this file manually!
    # It will be overwritten by the ALTER SYSTEM command.
    # Recovery settings generated by pgBackRest restore on 2024-03-13 20:47:11
    restore_command = 'pgbackrest --config-path=/mnt/disks/pgsql --pg1-path=/mnt/disks/pgsql/data --repo=1 --stanza=db archive-get %f "%p"'
    recovery_target = 'immediate'
    recovery_target_action = 'promote'
    recovery_target_timeline = 'current'

  5. En el servidor de destino, inicia el servicio de la base de datos:

    Docker 

    docker start CONTAINER_NAME

    Podman 

    podman start CONTAINER_NAME

Una vez que se haya iniciado el servicio de base de datos, puedes conectarte a la instancia principal y ejecutar consultas para verificar que los datos se han restaurado a partir de la copia de seguridad. Para obtener más información, consulta Conectarse a AlloyDB Omni en un solo servidor.

Siguientes pasos