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:
- Ermitteln Sie die Informationen zum Sicherungslaufwerk für das Sicherungslaufwerk des Quelldatenbankclusters, z. B. den Namen des nichtflüchtigen Volumes und den Handle des nichtflüchtigen Compute Engine-Speichers.
- Hängen Sie die Sicherungsfestplatte des Quelldatenbankclusters auf dem Zielserver ein.
- Verwenden Sie
pgBackRest-Befehle, um zu prüfen, ob auf Quellsicherungen zugegriffen werden kann. - 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
postgresin 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.
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 backupdiskErsetzen 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 ```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.
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.volumeHandleErsetzen 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-cb5969b446c3Exportieren 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 eine Verbindung zum Server her und hängen Sie die Sicherungsdisk ein.
Führen Sie den Befehl
gcloud compute instances attach-diskaus, um das Laufwerk bereitzustellen:gcloud compute instances attach-disk GCE_INSTANCE_NAME \ --disk ${BACKUP_DISK} \ --zone=$GCE_ZONEErsetzen 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.
Stellen Sie das Sicherungslaufwerk für den Zielserver bereit:
lsblk mkdir -p /mnt/disks/backupdisk mount -o discard,defaults /dev/sdb /mnt/disks/backupdiskFügen Sie der AlloyDB Omni-Datei
dataplane.confim Verzeichnis/var/alloydb/configeine 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.
- Starten Sie den Zielserver neu:
Docker
docker restart CONTAINER_NAMEErsetzen Sie CONTAINER_NAME durch den Namen eines neuen AlloyDB Omni-Containers, z. B. my-omni-1.
Podman
podman restart CONTAINER_NAMEErsetzen Sie CONTAINER_NAME durch den Namen eines neuen AlloyDB Omni-Containers, z. B. my-omni-1.
pgBackRest-Konfigurationsdatei aktualisieren
Aktualisieren Sie die vorhandene Datei pgBackRest im Verzeichnis der Sicherungsfestplatte mit dem neuen Repository-Pfad.
Wechseln Sie auf dem Zielserver in das Verzeichnis
/mnt/disks/backupdisk:cd /mnt/disks/backupdiskAktualisieren Sie den Pfad
pg1-pathin der Dateipgbackrest.confauf ein temporäres Verzeichnis, um zu vermeiden, dass die vorhandenen Daten überschrieben werden. Das Verzeichnisdata-restoredwird im Rahmen der Wiederherstellung automatisch erstellt:sudo sed -i 's|.*pg1-path.*|pg1-path=/mnt/disks/pgsql/data-restored|' pgbackrest.confAktualisieren Sie den Pfad
repo1-pathauf ein temporäres Verzeichnis in der Dateipgbackrest.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:
Docker
sudo docker exec CONTAINER_NAME pgbackrest --config-path=/mnt/disks/backups --stanza=db --repo=1 infoPodman
sudo podman exec CONTAINER_NAME pgbackrest --config-path=/mnt/disks/backups --stanza=db --repo=1 infoHier 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 die Wiederherstellung zu einem bestimmten Zeitpunkt im Wiederherstellungszeitraum durchzuführen.
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=infoVon 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.
Beenden Sie auf dem Zielserver den Datenbankdienst:
Docker
docker stop CONTAINER_NAMEPodman
podman stop CONTAINER_NAMEBenennen Sie das aktuelle Datenverzeichnis um:
mv ~/alloydb-data/data ~/alloydb-data/data-oldBenennen Sie das temporäre Verzeichnis
data-restoredin das aktuelle Datenverzeichnis um:mv ~/alloydb-data/data-restored ~/alloydb-data/dataAktualisieren Sie den Wert
pg1-pathin der Dateipostgresql.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'Starten Sie auf dem Zielserver den Datenbankdienst:
Docker
docker start CONTAINER_NAMEPodman
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.