Clonar un clúster de base de datos en Kubernetes mediante una copia de seguridad local

Selecciona una versión de la documentación:

En este documento se describe cómo clonar un clúster de base de datos en Kubernetes mediante una copia de seguridad local de un clúster de base de datos de AlloyDB Omni.

En este documento, se da por sentado lo siguiente:

  • Los clústeres de bases de datos de origen y de destino se crean en Google Kubernetes Engine, y los discos de copia de seguridad son discos persistentes de Compute Engine.
  • Los discos persistentes de Compute Engine que se usan como disco de copia de seguridad en la base de datos no los usan otros clústeres de bases de datos.

Cuando clonas un clúster de bases de datos, sigues estos pasos:

  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. Asegúrate de que hayas habilitado la función de copia de seguridad del clúster de base de datos de origen y de que tengas al menos una copia de seguridad correcta. Si no se cumplen estas condiciones, sigue las instrucciones que se indican en Habilitar y programar copias de seguridad.
  2. Crea un recurso PersistentVolume para usar un disco de copia de seguridad en el clúster de base de datos de destino y acceder al disco de copia de seguridad del clúster de base de datos de origen.
  3. Crea y aplica el archivo de manifiesto de recursos DBCluster en el clúster de base de datos de destino con el parámetro livenessProbe inhabilitado y la información del disco de copia de seguridad añadida.
  4. Usa los comandos pgBackRest para verificar que se puede acceder a las copias de seguridad de origen.
  5. 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.
  • El disco de copia de seguridad del clúster de la base de datos de origen debe poder montarse en el clúster de la base de datos de destino. Para obtener más información, consulta Volúmenes persistentes. Si el backend de almacenamiento subyacente no admite el acceso ReadOnlyMany (ROX), asegúrese de que ningún pod del clúster de origen esté usando el disco de copia de seguridad.
  • Como el disco de copia de seguridad de origen está montado en el clúster de la base de datos de destino, el archivo pgBackRest.conf se reutiliza tal cual.
  • 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 localizar el nombre del PV subyacente y el controlador de Persistent Disk 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 mediante el identificador del controlador de disco.

  1. 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

    Haz los cambios siguientes:

    • DB_CLUSTER_NAMESPACE: el espacio de nombres de Kubernetes de este plan de 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.

        backuprepodisk-my-db-cluster-br-0   Bound
    pvc-36d8f05d-ef1a-4750-ac01-9bb330c15b3a   10Gi       RWO            standard-rwo   5d21h

  2. 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 del PV subyacente y el controlador de Persistent Disk de Compute Engine:

      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, backuprepodisk-my-db-cluster-br-0.

  3. Exporte las configuraciones basadas en el nombre del PV como variables que se usarán en las secciones posteriores:

      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}")

    Haz los cambios siguientes:

    • PV_NAME: el nombre del volumen persistente del disco de copia de seguridad de la respuesta del paso anterior. Por ejemplo, "backupDiskVolume".

Crear un recurso de volumen persistente

Crea un recurso PersistentVolume con el nombre del controlador de disco.

  1. En el clúster de Kubernetes de destino, crea el archivo de manifiesto 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}"

    Haz los cambios siguientes:

    • PV_NAME: nombre del recurso PersistentVolume que se va a crear.

  2. Aplica el archivo de manifiesto:

      kubectl apply -f PV_FILENAME

    Haz los cambios siguientes:

    • PV_FILENAME: el nombre del archivo de manifiesto PersistentVolume creado en el paso anterior.

Crear un clúster de base de datos de destino

Crea un clúster de bases de datos inhabilitando temporalmente el parámetro livenessProbe. Cuando finalice la restauración, vuelve a configurar el parámetro livenessProbe.

  1. 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:
    databaseVersion: "15.5.5"
    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

    Haz los cambios siguientes:

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

    • ENCODED_PASSWORD: la contraseña de inicio de sesión de la base de datos del rol de usuario postgres predeterminado, codificada como una cadena base64. Por ejemplo, Q2hhbmdlTWUxMjM= para ChangeMe123.

    • CPU_COUNT: número de CPUs disponibles para cada instancia de base de datos de este clúster de bases de datos.

    • MEMORY_SIZE: la cantidad de memoria por instancia de base de datos de este clúster de bases de datos. Te recomendamos que lo configures en 8 gigabytes por CPU. Por ejemplo, si asignas el valor 2 a CPU_COUNT, te recomendamos que asignes el valor 16Gi a memory.

    • DATA_DISK_SIZE: el tamaño del disco por instancia de base de datos. Por ejemplo, 10Gi.

  2. Aplica el archivo de manifiesto:

      kubectl apply -f DBCLUSTER_FILENAME

    Haz los cambios siguientes:

    • DBCLUSTER_FILENAME: el nombre del archivo de manifiesto DBCluster creado en el paso anterior.

Usa el comando kubectl describe para verificar que el recurso del clúster de la base de datos tiene el estado READY.

Verificar 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 puede acceder a las copias de seguridad del clúster de base de datos de origen en el clúster de base de datos de destino.

  1. 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.

  2. Inicia sesión en el pod de la base de datos:

      kubectl exec -ti DATABASE_POD_NAME  -- /bin/bash

    Haz los cambios siguientes:

    • DATABASE_POD_NAME : el nombre del pod del clúster de la base de datos del paso anterior.

  3. Detén el pod antes de actualizar el archivo de configuración pgBackRest:

      supervisorctl.par stop postgres

  4. Actualiza el archivo de configuración 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

  5. 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 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 clúster de base de datos de destino

Una vez que hayas identificado la copia de seguridad o el punto en el tiempo al que quieres restaurar los datos, 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 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=/backup --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=/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

Reiniciar el pod

Una vez que se haya completado correctamente el comando de restauración, puedes iniciar el proceso de postgres.

supervisorctl.par start postgres

Una vez que se inicie el proceso de postgres, 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 Kubernetes.

Configurar el clúster de bases de datos

Después de clonar un clúster de bases de datos, configura sus especificaciones. Asegúrate de activar el parámetro livenessProbe con el siguiente comando:

    kubectl patch dbcluster DBCLUSTER_FILENAME --type merge -p '{"spec":{"primarySpec":{"availabilityOptions":{"livenessProbe":"Enabled"}}}}'

Siguientes pasos