Questa pagina documenta la versione 15.5.2 di AlloyDB Omni utilizzando l'opzione di deployment container. Scegli un'altra opzione di implementazione.

Questa pagina è stata tradotta dall'API Cloud Translation.

Clonare un cluster di database in Kubernetes utilizzando un backup locale

Seleziona una versione della documentazione:

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

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

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

Identifica le informazioni sul disco di backup, come il nome del volume permanente e l'handle del disco permanente di Compute Engine, per il disco di backup del cluster di database di origine.
Crea una risorsa PersistentVolume per utilizzare un disco di backup esistente nel cluster di database di destinazione per accedere al disco di backup del cluster di database di origine.
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.
Utilizza i comandi pgBackRest per verificare che sia possibile accedere ai backup delle origini.
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 di database di origine.
Il disco di backup del cluster di database di origine deve essere in grado di essere montato sul cluster di database di destinazione. Per ulteriori informazioni sui passaggi 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.

Recuperare le informazioni sul disco di backup di origine

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

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

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 backupdisk
```
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.
```
    backupdisk-al-fe8c-my-db-cluster-0   Bound
    pvc-36d8f05d-ef1a-4750-ac01-9bb330c15b3a   10Gi       RWO            standard-rwo   5d21h
```
Utilizza il nome del PVC del disco di backup del passaggio precedente, ad esempio backupdisk-al-fe8c-my-db-cluster-0, per trovare il nome del PV sottostante e l'handle del disco permanente di Compute Engine:
```
  kubectl get pvc/PVC_NAME -n DB_CLUSTER_NAME -o jsonpath={.spec.volumeName}
```
Sostituisci quanto segue:
- PVC_NAME: il nome del PVC del disco di backup dalla risposta del passaggio precedente, ad esempio backupdisk-al-fe8c-dbcluster-sample-0.

Esporta le configurazioni in base al nome del 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 PV del disco di backup dalla risposta del passaggio precedente.

Crea una risorsa del volume permanente nel cluster di database di destinazione

Utilizzando il nome del gestore del disco, crea una risorsa PersistentVolume.

Nel cluster di 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}"

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 mentre il processo di ripristino viene completato.

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 utente postgres predefinito, codificata come stringa base64, ad esempio Q2hhbmdlTWUxMjM= per ChangeMe123.

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 dell'origine nel cluster di database di destinazione

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

Nel cluster di database di destinazione, trova i dettagli del pod del cluster di 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.
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.
Arresta il pod prima di aggiornare il file di configurazione pgBackRest:
```
  supervisorctl.par stop postgres
```

Verifica i backup dell'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 momento specifico della finestra di recupero.

Ripristina il backup nel cluster di database di destinazione

Dopo aver identificato il backup o un momento specifico a cui eseguire il ripristino, esegui i comandi pgBackRest nel cluster di database di destinazione. Per ulteriori informazioni su questi comandi, consulta Restore Command.

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 correttamente il comando di ripristino, puoi avviare la procedura di postgres.

supervisorctl.par start postgres

Una volta avviato il processo postgres, puoi connetterti all'istanza primaria ed eseguire query per verificare che i dati vengano ripristinati dal backup. Per saperne di più, consulta Connettersi ad AlloyDB Omni in esecuzione su Kubernetes.

Passaggi successivi

Clonare un cluster di database in Kubernetes utilizzando un backup di Cloud Storage