Datenbankcluster mithilfe einer lokalen Sicherung auf einem einzelnen Server klonen

Bei den Schritten auf dieser Seite wird davon ausgegangen, dass der Kubernetes-Quelldatenbankcluster in Google Kubernetes Engine erstellt wurde und die Sicherungs-Volumes Compute Engine-Volumes sind. Außerdem wird davon ausgegangen, dass der AlloyDB Omni-Zielserver auf einer Compute Engine-VM installiert ist.

Wenn Sie andere Umgebungen verwenden, lesen Sie die entsprechende Dokumentation, um diese Schritte in Ihrer Umgebung zu replizieren.

Im folgenden Workflow werden die Schritte zum Klonen beschrieben:

1. Ermitteln Sie die Informationen zum Sicherungslaufwerk für das Quelldatenbankcluster, z. B. den Namen des nichtflüchtigen Volumes und den Handle des nichtflüchtigen Compute Engine-Speichers.
2. Hängen Sie die Sicherungsfestplatte des Quelldatenbankclusters auf dem Zielserver ein.
3. Verwenden Sie pgBackRest-Befehle, um zu prüfen, ob auf Quellsicherungen zugegriffen werden kann.
4. Verwenden Sie pgBackRest-Befehle, um die Sicherung im Zieldatenbankcluster wiederherzustellen.

Hinweise

• Achten Sie darauf, dass Sie Zugriff auf die Sicherungsfestplatte haben, auf der die Sicherung Ihres Quelldatenbankclusters gespeichert ist.
• Es wird ein AlloyDB Omni-Datenbankcluster mit einem einzelnen Server als Ziel erstellt. Weitere Informationen zur Installation von AlloyDB Omni in Kubernetes finden Sie unter AlloyDB Omni installieren.
• Achten Sie darauf, dass Sie als Nutzer postgres in der Datenbank angemeldet sind.

Informationen zum Quellsicherungsmedium abrufen

Bestimmen Sie im Rahmen des Wiederherstellungsvorgangs den Namen des Anspruchs auf nichtflüchtiges Volume (Persistent Volume Claim, PVC) für das Sicherungslaufwerk für Ihren Quelldatenbankcluster. PVCs werden in Kubernetes verwendet, um nichtflüchtigen Speicher für Anwendungen zu verwalten.

Mit den folgenden Beispielbefehlen können Sie den zugrunde liegenden PV-Namen und den Compute Engine-Handler für nichtflüchtige Speicher anhand des PVC-Namens des Sicherungslaufwerks ermitteln.

1. Stellen Sie eine Verbindung zu Ihrem GKE-Cluster her, in dem Sie den AlloyDB Omni-Quelldatenbankcluster erstellt haben:

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

   Ersetzen Sie Folgendes:

   • DB_CLUSTER_NAMESPACE: der Kubernetes-Namespace für dieses Backup. Er muss mit dem Namespace des Datenbankclusters übereinstimmen.

   • DB_CLUSTER_NAME: Der Name dieses Datenbankclusters, z. B. my-db-cluster.

   Hier ist die Beispielantwort.

     backupdisk-al-fe8c-dbcluster-sample-0   Bound
     pvc-36d8f05d-ef1a-4750-ac01-9bb330c15b3a   10Gi       RWO            standard-rwo   5d21h
     ```

2. Verwenden Sie den Namen des Sicherungslaufwerks aus dem vorherigen Schritt, z. B. backupdisk-al-fe8c-dbcluster-sample-0, um den zugrunde liegenden PV-Namen zu finden:

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

   Ersetzen Sie Folgendes:

   • PVC_NAME: Der PVC-Name des Sicherungslaufwerks aus der Antwort im vorherigen Schritt, z. B. backupdisk-al-fe8c-dbcluster-sample-0.

3. Suchen Sie den zugrunde liegenden Handler für den nichtflüchtigen Compute Engine-Speicher:

     kubectl get pv/$PV_NAME -o json | jq -r .spec.csi.volumeHandle

   Ersetzen Sie Folgendes:

   • PV_NAME: Der PV-Name des Sicherungslaufwerks aus der Antwort im vorherigen Schritt.

   Hier ist die Beispielantwort:

     projects/my-project/zones/us-central1-a/disks/pvc-89f91fba-6cd2-4bfa-84ed-cb5969b446c3

4. Exportieren Sie den Namen des Sicherungsdatenträgers als Variable, die in den nächsten Abschnitten verwendet wird:

     export BACKUP_DISK=pvc-89f91fba-6cd2-4bfa-84ed-cb5969b446c3

Sicherungsfestplatte auf dem Zielserver bereitstellen

Angenommen, der Zielserver ist ein AlloyDB Omni-Server, der auf einer Compute Engine-VM installiert ist, stellen Sie die Sicherungsdisk auf dem Server bereit.

1. Führen Sie den Befehl gcloud compute instances attach-disk aus, um das Laufwerk bereitzustellen:

     gcloud compute instances attach-disk GCE_INSTANCE_NAME \
     --disk ${BACKUP_DISK} \
     --zone=$GCE_ZONE

   Ersetzen Sie Folgendes:

   • GCE_INSTANCE_NAME: der Name der Instanz, auf der Ihr Zielserver auf der Compute Engine-VM installiert ist.

   • GCE_ZONE: die Zone, in der sich Ihre Compute Engine-VM-Instanz befindet.

2. Stellen Sie das Sicherungslaufwerk für den Zielserver bereit:

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

3. Fügen Sie der AlloyDB Omni-Datei dataplane.conf im Verzeichnis /var/alloydb/config eine benutzerdefinierte Bind-Mount-Option hinzu:

     PG_BIND_MOUNTS=/mnt/disks/backupdisk:/mnt/disks/backups:rshared

Weitere Informationen zu Bind-Mounts in Docker finden Sie unter Bind-Mounts.

1. Starten Sie den Zielserver neu:

  docker restart CONTAINER_NAME

  podman restart CONTAINER_NAME

pgBackRest-Konfigurationsdatei aktualisieren

Aktualisieren Sie die vorhandene Datei pgBackRest im Verzeichnis der Sicherungsfestplatte mit dem neuen Repository-Pfad.

1. Wechseln Sie auf dem Zielserver in das Verzeichnis /mnt/disks/backupdisk:

     cd /mnt/disks/backupdisk

2. Aktualisieren Sie den Pfad pg1-path in der Datei pgbackrest.conf auf ein temporäres Verzeichnis, um zu vermeiden, dass die vorhandenen Daten überschrieben werden. Das Verzeichnis data-restored wird im Rahmen der Wiederherstellung automatisch erstellt:

     sudo sed -i 's|.*pg1-path.*|pg1-path=/mnt/disks/pgsql/data-restored|' pgbackrest.conf

3. Aktualisieren Sie den Pfad repo1-path auf ein temporäres Verzeichnis in der Datei pgbackrest.conf:

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

Quellsicherungen im Zieldatenbankcluster überprüfen

Melden Sie sich auf dem Zielserver an und führen Sie pgBackRest-Befehle aus, um zu prüfen, ob die Sicherungen des Quelldatenbankclusters auf dem Zielserver verfügbar sind:

  sudo docker exec CONTAINER_NAME pgbackrest --config-path=/mnt/disks/backups --stanza=db --repo=1 info

  sudo podman exec CONTAINER_NAME pgbackrest --config-path=/mnt/disks/backups --stanza=db --repo=1 info

Hier ist eine Beispielantwort:

    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

Die Zeitstempel in der Antwort werden entweder verwendet, um die vollständige Sicherung oder die Sicherung zu einem bestimmten Zeitpunkt aus dem Wiederherstellungszeitraum wiederherzustellen.

Sicherung auf dem Zielserver wiederherstellen

Nachdem Sie die Sicherung oder den Zeitpunkt ermittelt haben, zu dem Sie die Wiederherstellung durchführen möchten, führen Sie pgBackRest-Befehle auf dem Zielserver aus. Weitere Informationen zu diesen Befehlen finden Sie unter Restore-Befehl.

Im Folgenden finden Sie einige Beispiele für pgBackRest-Wiederherstellungsbefehle:

• Aus einer Sicherung wiederherstellen

  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

• Von einem bestimmten Zeitpunkt wiederherstellen

  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

Daten auf Zielserver kopieren

Nachdem der Wiederherstellungsbefehl erfolgreich abgeschlossen wurde, können Sie die Daten aus dem temporären Verzeichnis data-restored in das aktuelle AlloyDB-Datenverzeichnis kopieren.

1. Beenden Sie auf dem Zielserver den Datenbankdienst:

   Docker

   docker stop CONTAINER_NAME

   Podman

   podman stop CONTAINER_NAME

2. Benennen Sie das aktuelle Datenverzeichnis um:

     mv ~/alloydb-data/data  ~/alloydb-data/data-old

3. Benennen Sie das temporäre Verzeichnis data-restored in das aktuelle Datenverzeichnis um:

     mv ~/alloydb-data/data-restored ~/alloydb-data/data

4. Aktualisieren Sie den Wert pg1-path in der Datei postgresql.auto.conf, um die wiederhergestellten Daten zu laden:

       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'

5. Starten Sie auf dem Zielserver den Datenbankdienst:

   Docker

   docker start CONTAINER_NAME

   Podman

   podman start CONTAINER_NAME

Nachdem der Datenbankdienst gestartet wurde, können Sie eine Verbindung zur primären Instanz herstellen und Abfragen ausführen, um zu prüfen, ob die Daten aus der Sicherung wiederhergestellt wurden. Weitere Informationen finden Sie unter Verbindung zu AlloyDB Omni auf einem einzelnen Server herstellen.

Nächste Schritte

• Datenbankcluster auf einem einzelnen Server mit einer Cloud Storage-Sicherung klonen