Cómo clonar un clúster de bases de datos en Kubernetes con una copia de seguridad local

Selecciona una versión de la documentación:

En esta página, se muestra cómo clonar un clúster de base de datos en Kubernetes con una copia de seguridad local de un clúster de base 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 crearon en Google Kubernetes Engine y que los discos de copia de seguridad son discos persistentes de Compute Engine. También supone que ningún otro clúster de base de datos usa los discos persistentes de Compute Engine que se utilizan como copia de seguridad en la base de datos.

En el siguiente flujo de trabajo, se explican los pasos que se usan 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, para el disco de copia de seguridad del clúster de la base de datos de origen.
  2. Crea un recurso PersistentVolume para usar un disco de copia de seguridad existente 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 del recurso DBCluster en el clúster de la base de datos de destino con el parámetro livenessProbe inhabilitado y la información del disco de copia de seguridad agregada.
  4. Usa los comandos pgBackRest para verificar que se pueda acceder a las copias de seguridad de la fuente.
  5. Usa los comandos pgBackRest para restablecer la copia de seguridad en el clúster de la 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 que debes seguir para asegurarte de que el disco se pueda activar, consulta Volúmenes persistentes.
  • Dado que el disco de copia de seguridad de origen está montado en el clúster de base de datos de destino, el archivo pgBackRest.conf se reutiliza tal cual.
  • 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 ejemplo ayudan a ubicar el nombre del PV subyacente y el controlador del 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 todas las VMs de Compute Engine con el identificador del controlador de disco.

  1. Conéctate a tu 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 backupdisk

    Reemplaza lo siguiente:

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

    • DB_CLUSTER_NAME: Es 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-my-db-cluster-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, backupdisk-al-fe8c-my-db-cluster-0) para encontrar el nombre del PV subyacente y el controlador del disco persistente de Compute Engine:

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

    Reemplaza lo siguiente:

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

  3. Exporta las configuraciones según el nombre del PV como variables para usarlas 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

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

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

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

Crea un clúster de base de datos de destino

Crea un clúster de base de datos inhabilitando temporalmente el parámetro livenessProbe mientras se completa el proceso de restablecimiento.

  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:
    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 base de datos, por ejemplo, my-db-cluster.

    • ENCODED_PASSWORD: Es la contraseña de acceso a la base de datos para el rol de usuario postgres predeterminado, codificada como una cadena en base64 (por ejemplo, Q2hhbmdlTWUxMjM= para ChangeMe123).

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

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

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

Ejecuta comandos de 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.

  1. En el clúster de la base de datos de destino, busca los detalles del pod del clúster de la 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. 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 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. 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 del período de recuperación.

Restablece la copia de seguridad en el clúster de la base de datos de destino

Después de identificar la copia de seguridad o el momento al que deseas restablecer la base de 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 incluyen algunos ejemplos de comandos de restauración de pgBackRest:

  • 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 el comando de restablecimiento se complete correctamente, puedes iniciar el proceso de 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 restablecieron desde la copia de seguridad. Para obtener más información, consulta Cómo conectarse a AlloyDB Omni que se ejecuta en Kubernetes.

¿Qué sigue?