Clonare un cluster di database in Kubernetes utilizzando un backup locale

Questa pagina mostra come clonare un cluster di database in Kubernetes utilizzando il backup locale di un cluster di database AlloyDB Omni.

I passaggi in questa pagina presuppongono che i cluster di database di origine e di destinazione siano stati creati su Google Kubernetes Engine e che i dischi di backup siano dischi di Compute Engine permanenti. Inoltre, presuppone che i dischi permanenti di Compute Engine utilizzati come backup nel database non siano utilizzati da nessun altro cluster di database.

Il seguente flusso di lavoro spiega i passaggi utilizzati per la clonazione:

  1. Identifica le informazioni sul disco di backup, ad esempio il nome del volume permanente e il gestore del disco permanente di Compute Engine, per il disco di backup del cluster del database di origine.
  2. Crea una risorsa PersistentVolume per utilizzare un disco di backup esistente sul cluster di database di destinazione per accedere al disco di backup del cluster di database di origine.
  3. Crea e applica il file manifest della risorsa DBCluster sul cluster di database di destinazione con il parametro livenessProbe disattivato e le informazioni sul disco di backup aggiunte.
  4. Utilizza i comandi pgBackRest per verificare che sia possibile accedere ai backup di origine.
  5. Utilizza i comandi pgBackRest per ripristinare il backup nel cluster di database di destinazione.

Prima di iniziare

  • Assicurati di avere accesso al disco di backup in cui è archiviato il backup del cluster del database di origine.
  • Il disco di backup del cluster del database di origine deve essere in grado di montarsi sul cluster del database di destinazione. Per ulteriori informazioni sulla procedura per assicurarti che il disco sia montabile, consulta Volumi permanenti.
  • Poiché il disco di backup di origine è montato sul cluster di database di destinazione, il file pgBackRest.conf viene riutilizzato così com'è.
  • Assicurati di aver eseguito l'accesso al database come utente postgres.

Visualizzare le informazioni sul disco di backup di origine

Nell'ambito della procedura di ripristino, determina il nome della richiesta di volume permanente (PVC) del disco di backup per il cluster del database di origine. I PVC vengono utilizzati in Kubernetes per gestire lo spazio di archiviazione permanente per le applicazioni.

I seguenti comandi di esempio consentono di individuare il nome della PV sottostante e il gestore del disco permanente di Compute Engine. Nell'esempio, tutti i dischi di backup sono dischi permanenti di Compute Engine, a cui è possibile accedere nelle VM Compute Engine utilizzando l'identificatore dell'handle del disco.

  1. Connettiti al cluster di database di destinazione per trovare il nome del PVC:

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

    Sostituisci quanto segue:

    • DB_CLUSTER_NAMESPACE: lo spazio dei nomi Kubernetes per questo piano di backup. Deve corrispondere allo spazio dei nomi del cluster di database.

    • DB_CLUSTER_NAME: il nome di questo cluster di database, ad esempio my-db-cluster.

    Di seguito è riportata la risposta di esempio.

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

  2. Utilizza il nome del PVC del disco di backup del passaggio precedente, ad esempio backuprepodisk-my-db-cluster-br-0, per trovare il nome del PV sottostante e il gestore del disco permanente di Compute Engine:

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

    Sostituisci quanto segue:

    • PVC_NAME: il nome del PVC del disco di backup dalla risposta nel passaggio precedente, ad esempio backuprepodisk-my-db-cluster-br-0.

  3. Esporta le configurazioni in base al nome della PV come variabili da utilizzare nelle sezioni successive:

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

    Sostituisci quanto segue:

    • PV_NAME: il nome del disco di backup del PV dalla risposta del passaggio precedente.

Crea la risorsa volume permanente nel cluster di database di destinazione

Utilizza il nome del gestore del disco per creare una risorsa PersistentVolume.

  1. Nel cluster del database di destinazione, crea il file manifest 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. Applica il file manifest:

      kubectl apply -f PV_FILENAME

    Sostituisci quanto segue:

    • PV_FILENAME: il nome del file manifest PersistentVolume creato nel passaggio precedente.

Crea un cluster di database di destinazione

Crea un cluster di database disattivando temporaneamente il parametro livenessProbe al termine del processo di ripristino.

  1. Crea il file manifest 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

    Sostituisci quanto segue:

    • DB_CLUSTER_NAME: il nome di questo cluster di database, ad esempio my-db-cluster.

    • ENCODED_PASSWORD: la password di accesso al database per il ruolo postgres utente predefinito, codificata come stringa base64, ad esempio Q2hhbmdlTWUxMjM= per ChangeMe123.

  2. Applica il file manifest:

      kubectl apply -f DBCLUSTER_FILENAME

    Sostituisci quanto segue:

    • DBCLUSTER_FILENAME: il nome del file manifest DBCluster creato nel passaggio precedente.

Utilizza il comando kubectl describe per verificare che la risorsa del cluster di database sia nello stato READY.

Verifica i backup di origine nel cluster di database di destinazione

Esegui i comandi pgBackRest per verificare che i backup del cluster del database di origine siano accessibili nel cluster del database di destinazione.

  1. Nel cluster del database di destinazione, trova i dettagli del pod del cluster del database:

      kubectl get pod -l "alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME, alloydbomni.internal.dbadmin.goog/task-type=database"

    La risposta include il nome del pod del database del cluster.

  2. Accedi al pod del database:

      kubectl exec -ti DATABASE_POD_NAME  -- /bin/bash

    Sostituisci quanto segue:

    • DATABASE_POD_NAME : il nome del pod del cluster di database del passaggio precedente.

  3. Interrompi il pod prima di aggiornare il file di configurazione pgBackRest:

      supervisorctl.par stop postgres

  4. Aggiorna il file di configurazione 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

  5. Verifica i backup di origine nel pod del cluster di database:

    pgbackrest --config-path=/backup --stanza=db --repo=1 info

    Di seguito è riportato un esempio di risposta:

      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

I timestamp nella risposta vengono utilizzati per ripristinare il backup completo o per ripristinare da un punto nel tempo della finestra di recupero.

Ripristina il backup nel cluster di database di destinazione

Dopo aver identificato il backup o un punto in cui vuoi eseguire il ripristino, esegui i comandi pgBackRest nel cluster di database di destinazione. Per ulteriori informazioni su questi comandi, consulta Comando di ripristino.

Di seguito sono riportati alcuni comandi di ripristino pgBackRest di esempio:

  • Ripristina da un backup

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

  • Ripristina da un momento specifico

    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

Riavvia il pod

Una volta completato il comando di ripristino, puoi avviare la procedura postgres.

supervisorctl.par start postgres

Dopo l'avvio del processo postgres, puoi connetterti all'istanza principale ed eseguire query per verificare che i dati vengano ripristinati dal backup. Per ulteriori informazioni, consulta Connettersi ad AlloyDB Omni in esecuzione su Kubernetes.

Passaggi successivi