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 un singolo server utilizzando un backup locale

Seleziona una versione della documentazione:

Questa pagina mostra come clonare un cluster di database in un singolo server utilizzando il backup locale.

I passaggi descritti in questa pagina presuppongono che il cluster di database Kubernetes di origine sia creato su Google Kubernetes Engine e che i dischi di backup siano dischi permanenti Compute Engine. Inoltre, presuppone che il server singolo AlloyDB Omni di destinazione sia installato su una macchina virtuale (VM) Compute Engine.

Se utilizzi altri ambienti, consulta la documentazione relativa per replicare questi passaggi nel tuo ambiente.

Il seguente flusso di lavoro spiega i passaggi di clonazione:

Identifica le informazioni sul disco di backup, come il nome del volume permanente e l'handle del disco permanente Compute Engine, per il disco di backup del cluster di database di origine.
Monta il disco di backup del cluster di database di origine sul server di destinazione.
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.
Viene creato un singolo cluster di database AlloyDB Omni di destinazione del server. Per saperne di più sull'installazione di AlloyDB Omni su Kubernetes, consulta Installa AlloyDB Omni.
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 determinare il nome del PV sottostante e l'handle del disco permanente di Compute Engine utilizzando il nome del PVC del disco di backup.

Connettiti al cluster GKE in cui hai creato il cluster di database di origine AlloyDB Omni:
```
 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 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-dbcluster-sample-0   Bound
  pvc-36d8f05d-ef1a-4750-ac01-9bb330c15b3a   10Gi       RWO            standard-rwo   5d21h
  ```
```
Utilizza il nome del disco di backup del passaggio precedente, ad esempio backupdisk-al-fe8c-dbcluster-sample-0, per trovare il nome del PV sottostante:
```
  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 del passaggio precedente, ad esempio backupdisk-al-fe8c-dbcluster-sample-0.
Trova l'handler del disco permanente di Compute Engine sottostante:
```
  kubectl get pv/$PV_NAME -o json | jq -r .spec.csi.volumeHandle
```
Sostituisci quanto segue:
- PV_NAME: il nome del PV del disco di backup dalla risposta del passaggio precedente.
Di seguito è riportato un esempio di risposta:
```
  projects/my-project/zones/us-central1-a/disks/pvc-89f91fba-6cd2-4bfa-84ed-cb5969b446c3
```
Esporta il nome del disco di backup come variabile utilizzata nelle sezioni successive:
```
  export BACKUP_DISK=pvc-89f91fba-6cd2-4bfa-84ed-cb5969b446c3
```

Monta il disco di backup sul server di destinazione

Supponendo che il server di destinazione sia un server AlloyDB Omni installato su una macchina virtuale Compute Engine, monta il disco di backup sul server.

Esegui il comando gcloud compute instances attach-disk per montare il disco:
```
  gcloud compute instances attach-disk GCE_INSTANCE_NAME \
  --disk ${BACKUP_DISK} \
  --zone=$GCE_ZONE
```
Sostituisci quanto segue:
- GCE_INSTANCE_NAME: il nome dell'istanza in cui è installato il server di destinazione nella macchina virtuale Compute Engine.
- GCE_ZONE: la zona in cui esiste l'istanza di macchina virtuale Compute Engine.

Monta il disco di backup sul server di destinazione:

   lsblk
   mkdir -p /mnt/disks/backupdisk
   mount -o discard,defaults /dev/sdb /mnt/disks/backupdisk

Aggiungi un bind mount personalizzato al file dataplane.conf di AlloyDB Omni nella directory /var/alloydb/config:
```
  PG_BIND_MOUNTS=/mnt/disks/backupdisk:/mnt/disks/backups:rshared
```

Per saperne di più sui bind mount in Docker, consulta Bind mount.

Riavvia il server di destinazione:

  alloydb database-server stop
  alloydb database-server start

Aggiorna il file di configurazione `pgBackRest`

Aggiorna il file pgBackRest esistente nella directory del disco di backup con il nuovo percorso del repository.

Nel server di destinazione, vai alla directory /mnt/disks/backupdisk:
```
  cd /mnt/disks/backupdisk
```
Aggiorna il percorso pg1-path a una directory temporanea nel file pgbackrest.conf per evitare di sovrascrivere i dati esistenti. La directory data-restored viene creata automaticamente nell'ambito della procedura di ripristino:
```
  sudo sed -i 's|.*pg1-path.*|pg1-path=/mnt/disks/pgsql/data-restored|' pgbackrest.conf
```

Aggiorna il percorso repo1-path a una directory temporanea nel file pgbackrest.conf:

  sudo sed -i 's|.*repo1-path.*|repo1-path=/mnt/disks/backups/repo|' conf.d/repo1-local-backupplan.conf

Verifica i backup dell'origine nel cluster di database di destinazione

Accedi al server di destinazione ed esegui i comandi pgBackRest per verificare che i backup del cluster di database di origine siano accessibili sul server di destinazione:

    sudo docker exec pg-service pgbackrest --config-path=/mnt/disks/backups --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 server di destinazione

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

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

Ripristina da un backup

pgbackrest --config-path=/mnt/disks/backups --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=/mnt/disks/backups --stanza=db --repo=1 restore --target="2024-01-22 11:27:22" --type=time --target-action=promote --delta --link-all --log-level-console=info

Copiare i dati sul server di destinazione

Una volta completato correttamente il comando di ripristino, puoi copiare i dati dalla directory temporanea data-restored alla directory dei dati AlloyDB corrente.

Nel server di destinazione, arresta il servizio di database:
```
alloydb database-server stop
```
Rinomina la directory dei dati corrente con un altro nome come best practice:
```
  mv ~/alloydb-data/data  ~/alloydb-data/data-old
```
Rinomina la directory temporanea data-restored nella directory dei dati corrente:
```
  mv ~/alloydb-data/data-restored ~/alloydb-data/data
```

Aggiorna il valore pg1-path nel file postgresql.auto.conf per caricare i dati ripristinati:

    vim ~/alloydb-data/data/postgresql.auto.conf
    # Verify postgresql.auto.conf.
    # Do not edit this file manually!
    # It will be overwritten by the ALTER SYSTEM command.
    # Recovery settings generated by pgBackRest restore on 2024-03-13 20:47:11
    restore_command = 'pgbackrest --config-path=/mnt/disks/pgsql --pg1-path=/mnt/disks/pgsql/data --repo=1 --stanza=db archive-get %f "%p"'
    recovery_target = 'immediate'
    recovery_target_action = 'promote'
    recovery_target_timeline = 'current'

Nel server di destinazione, avvia il servizio di database:
```
alloydb database-server start
```

Dopo l'avvio del servizio di database, puoi connetterti all'istanza principale ed eseguire query per verificare che i dati vengano ripristinati dal backup. Per saperne di più, consulta Connessione ad AlloyDB Omni su un singolo server.

Passaggi successivi

Clonare un cluster di database in un singolo server utilizzando un backup di Cloud Storage