Questa pagina mostra la documentazione per la versione 15.7.0 di AlloyDB Omni.
Vai a Versioni della documentazione di AlloyDB Omni per scegliere una versione diversa.

Questa pagina è stata tradotta dall'API Cloud Translation.

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

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

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

Crea e applica il file manifest DBCluster al cluster di database di destinazione con il parametro livenessProbe disattivato.
Crea e configura il file pgbackrest.conf per accedere al backup di Cloud Storage.
Utilizza i comandi pgBackRest per verificare di poter accedere ai backup dell'origine.
Utilizza i comandi pgBackRest per ripristinare il backup nel cluster di database di destinazione.

Prima di iniziare

Assicurati di avere accesso al percorso completo del bucket Cloud Storage in cui è archiviato il backup del cluster del database di origine. Si tratta dello stesso percorso utilizzato per creare la risorsa BackupPlan per il cluster del database di origine.
Crea un cluster di database AlloyDB Omni di destinazione. Per ulteriori informazioni sull'installazione di AlloyDB Omni su Kubernetes, consulta Creare un cluster di database.
Assicurati di aver eseguito l'accesso al database come utente postgres.

Creare un cluster di database in un cluster di database di destinazione

Crea un cluster di database disattivando temporaneamente il parametro livenessProbe. Al termine del ripristino, riconfigura il parametro livenessProbe.

Crea il file manifest della risorsa 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
```
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.
- CPU_COUNT: il numero di CPU disponibili per ogni istanza di database in questo cluster di database.
- MEMORY_SIZE: la quantità di memoria per istanza di database di questo cluster di database. Ti consigliamo di impostare questo valore su 8 gigabyte per CPU. Ad esempio, se hai impostato cpu su 2 in precedenza in questo manifest, consigliamo di impostare memory su 16Gi.
- DISK_SIZE: le dimensioni del disco per istanza di database, ad esempio 10Gi.
Applica il file manifest:
```
  kubectl apply -f DBCLUSTER_FILENAME
```
Sostituisci quanto segue:
- DBCLUSTER_FILENAME: il nome del file manifestDBCluster creato nel passaggio precedente.

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

Configura il file `pgBackRest`

Configura il file pgBackRest per consentire al cluster di database di destinazione di accedere al bucket Cloud Storage in cui si trovano i backup di origine.

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

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

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

Accedi al pod:
```
  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.
Interrompi il pod prima di aggiornare il file di configurazione pgBackRest:
```
  supervisorctl.par stop postgres
```
Crea un file di configurazione pgBackRest per accedere ai backup archiviati in 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=/etc/ssl/certs/ca-certificates.crt
  repo1-retention-full=9999999
  repo1-gcs-key-type=auto
```
Sostituisci quanto segue:
- GCS_SOURCE_BACKUP_BUCKET_NAME: il nome del bucket Cloud Storage che hai creato durante la creazione del file manifest delle risorse BackupPlan per il cluster di database di origine. Non si tratta dell'URL completo del bucket; non anteporre il nome del bucket con gs://.
- GCS_SOURCE_BACKUP_BUCKET_PATH: il percorso della directory in cui l'operatore AlloyDB Omni scrive i backup all'interno del bucket Cloud Storage per il cluster del database di origine. Il percorso deve essere assoluto e deve iniziare con /.
repo1-gcs-key-type è impostato su auto per utilizzare l'account di servizio dell'istanza. Per ulteriori informazioni sulle altre opzioni, consulta Opzione Tipo chiave repository GCS.

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 sul cluster del database di destinazione.

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

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 maggiori informazioni, consulta Connettersi ad AlloyDB Omni in esecuzione su Kubernetes.

Configura il cluster di database

Dopo aver clonato un cluster di database, configura le relative specifiche. Soprattutto, non dimenticare di attivare il parametro livenessProbe con il seguente comando:

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

Passaggi successivi

Clonare un cluster di database in Kubernetes utilizzando un backup locale