Datenbankcluster mithilfe einer lokalen Sicherung auf einem einzelnen Server klonen

Auf dieser Seite erfahren Sie, wie Sie einen Datenbankcluster auf einem einzelnen Server mithilfe einer lokalen Sicherung klonen.

Bei den Schritten auf dieser Seite wird davon ausgegangen, dass der Quell-Kubernetes-Datenbankcluster in der Google Kubernetes Engine erstellt wird und die Sicherungslaufwerke persistente Laufwerke der Compute Engine sind. Außerdem wird davon ausgegangen, dass der AlloyDB Omni-Einzelserver auf einer Compute Engine-VM installiert ist.

Wenn Sie andere Umgebungen verwenden, lesen Sie die jeweilige Dokumentation, um diese Schritte in Ihrer Umgebung auszuführen.

Im folgenden Workflow werden die Schritte zum Klonen erläutert:

  1. Geben Sie die Informationen zum Sicherungslaufwerk für den Cluster der Quelldatenbank an, z. B. den Namen des nichtflüchtigen Volumes und den nichtflüchtigen Speicher-Handler der Compute Engine.
  2. Binden Sie das Sicherungslaufwerk des Quelldatenbankclusters auf dem Zielserver an.
  3. Prüfen Sie mit pgBackRest-Befehlen, ob auf die Quellsicherungen zugegriffen werden kann.
  4. Verwenden Sie pgBackRest-Befehle, um die Sicherung im Zieldatenbankcluster wiederherzustellen.

Hinweise

  • Sie benötigen Zugriff auf das Sicherungslaufwerk, auf dem das Back-up des 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.
  • Sie müssen als Nutzer postgres in der Datenbank angemeldet sein.

Informationen zum Quelllaufwerk für die Sicherung abrufen

Legen Sie im Rahmen der Wiederherstellung den Namen des Persistent Volume Claim (PVC) für das Sicherungslaufwerk für Ihren Quelldatenbankcluster fest. 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 nichtflüchtigen Speicher-Handler der Compute Engine 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 diese Sicherung. Er muss mit dem Namespace des Datenbankclusters übereinstimmen.

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

    Hier ist eine 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 ermitteln:

      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 nichtflüchtigen Speicher-Handler der Compute Engine:

      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 eine Beispielantwort:

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

  4. Exportieren Sie den Namen des Sicherungslaufwerks als Variable, die in den folgenden Abschnitten verwendet wird:

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

Sicherungslaufwerk auf dem Zielserver bereitstellen

Angenommen, der Zielserver ist ein AlloyDB Omni-Server, der auf einer Compute Engine-VM installiert ist, müssen Sie das Sicherungslaufwerk auf dem Server bereitstellen.

  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, in der der 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 auf dem 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 Bindung 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 

  docker restart CONTAINER_NAME

Ersetzen Sie CONTAINER_NAME durch den Namen eines neuen AlloyDB Omni-Containers, z. B. my-omni-1.

Podman 

  podman restart CONTAINER_NAME

Ersetzen Sie CONTAINER_NAME durch den Namen eines neuen AlloyDB Omni-Containers, z. B. my-omni-1.

Konfigurationsdatei pgBackRest aktualisieren

Aktualisieren Sie die vorhandene pgBackRest-Datei im Verzeichnis des Sicherungslaufwerks mit dem neuen Repositorypfad.

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

      cd /mnt/disks/backupdisk

  2. Aktualisieren Sie den Pfad pg1-path in der Datei pgbackrest.conf auf ein temporäres Verzeichnis, um zu verhindern, dass vorhandene 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 in der Datei pgbackrest.conf auf ein temporäres Verzeichnis:

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

Quellsicherungen im Zieldatenbankcluster prüfen

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

Docker 

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

Podman 

  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 wiederherzustellen oder um von einem bestimmten Zeitpunkt innerhalb des Wiederherstellungszeitraums wiederherzustellen.

Sicherung auf dem Zielserver wiederherstellen

Nachdem Sie die Sicherung oder einen Zeitpunkt ermittelt haben, zu dem Sie wiederherstellen möchten, führen Sie pgBackRest-Befehle auf dem Zielserver aus. Weitere Informationen zu diesen Befehlen finden Sie unter Befehl „Wiederherstellen“.

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 Befehl zum Wiederherstellen 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 sicherheitshalber in einen anderen Namen 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