En esta página se documenta la versión 16.8.0 de AlloyDB Omni con la opción de implementación de Kubernetes. Elige otra opción de implementación.

Esta página se ha traducido con Cloud Translation API.

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

Selecciona una versión de la documentación:

En esta página se explica cómo clonar un clúster de base de datos en Kubernetes mediante una copia de seguridad de Cloud Storage de un clúster de base de datos de AlloyDB Omni.

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

Crea y aplica el archivo de manifiesto DBCluster en el clúster de base de datos de destino con el parámetro livenessProbe inhabilitado.
Crea y configura el archivo pgbackrest.conf para acceder a la copia de seguridad de Cloud Storage.
Usa los comandos pgBackRest para verificar que puedes acceder a las copias de seguridad de la fuente.
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 a la ruta completa del segmento de Cloud Storage en el que se almacena la copia de seguridad del clúster de la base de datos de origen. Es la misma ruta que usaste al crear el recurso BackupPlan para tu clúster de base de datos de origen.
Crea un clúster de base de datos de AlloyDB Omni de destino. Para obtener más información sobre cómo instalar AlloyDB Omni en Kubernetes, consulta Crear un clúster de base de datos.
Asegúrate de haber iniciado sesión en la base de datos como usuario postgres.

Crear un clúster de bases de datos en un clúster de bases de datos de destino

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

Crea el archivo de manifiesto de recursos 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:
      cpu: CPU_COUNT
      memory: MEMORY_SIZE
      disks:
      - name: DataDisk
        size: DISK_SIZE
        storageClass: standard
```
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 has definido cpu como 2 en este manifiesto, te recomendamos que definas memory como 16Gi.
- DISK_SIZE: el tamaño del disco por instancia de base de datos. Por ejemplo, 10Gi.
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 de clúster de base de datos tiene el estado READY.

Configurar el archivo `pgBackRest`

Configura el archivo pgBackRest para que el clúster de la base de datos de destino pueda acceder al segmento de Cloud Storage en el que se encuentran las copias de seguridad de origen.

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.
Inicia sesión en el pod:
```
  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.
Detén el pod antes de actualizar el archivo de configuración pgBackRest:
```
supervisorctl.par stop postgres
```
Crea un archivo de configuración pgBackRest para acceder a las copias de seguridad almacenadas en 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=/scripts/ca-certificates.crt
  repo1-retention-full=9999999
  repo1-gcs-key-type=auto
```
Haz los cambios siguientes:
- GCS_SOURCE_BACKUP_BUCKET_NAME: el nombre del segmento de Cloud Storage que creaste al crear el archivo de manifiesto de recursos BackupPlan del clúster de la base de datos de origen. No es la URL completa del segmento. No añadas el prefijo gs:// al nombre del segmento.
- GCS_SOURCE_BACKUP_BUCKET_PATH: la ruta del directorio en el que el operador de AlloyDB Omni escribe las copias de seguridad, dentro del bucket de Cloud Storage del clúster de base de datos de origen. La ruta debe ser absoluta y empezar por /.
El valor de repo1-gcs-key-type es auto para usar la cuenta de servicio de la instancia. Para obtener más información sobre otras opciones, consulta Opciones de tipo de clave de repositorio de Cloud Storage.

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

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

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, 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 que se ejecuta en Kubernetes.

Siguientes pasos

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