Auf dieser Seite erfahren Sie, wie Sie einen Datenbankcluster in Kubernetes mithilfe einer lokalen Sicherung eines AlloyDB Omni-Datenbankclusters klonen.
Bei den Schritten auf dieser Seite wird davon ausgegangen, dass Ihre Quell- und Zieldatenbankcluster in der Google Kubernetes Engine erstellt wurden und die Sicherungslaufwerke nichtflüchtige Compute Engine-Laufwerke sind. Außerdem wird davon ausgegangen, dass die nichtflüchtigen Compute Engine-Laufwerke, die als Sicherung in der Datenbank verwendet werden, von keinem anderen Datenbankcluster verwendet werden.
Im folgenden Workflow werden die Schritte zum Klonen erläutert:
- Geben Sie die Informationen zum Sicherungslaufwerk an, z. B. den Namen des nichtflüchtigen Volumes und den nichtflüchtigen Speicher-Handler der Compute Engine, für das Sicherungslaufwerk des Quelldatenbankclusters.
- Erstellen Sie eine
PersistentVolume-Ressource, um ein vorhandenes Sicherungslaufwerk im Zieldatenbankcluster für den Zugriff auf das Sicherungslaufwerk des Quelldatenbankclusters zu verwenden. - Erstellen und wenden Sie die Ressourcenmanifestdatei
DBClusterauf dem Zieldatenbankcluster an. Dabei muss der ParameterlivenessProbedeaktiviert und Informationen zum Sicherungslaufwerk hinzugefügt werden. - Prüfen Sie mit
pgBackRest-Befehlen, ob auf die Quellsicherungen zugegriffen werden kann. - 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.
- Das Sicherungslaufwerk des Quelldatenbankclusters muss am Zieldatenbankcluster bereitgestellt werden können. Weitere Informationen dazu, wie Sie dafür sorgen, dass Ihr Laufwerk bereitgestellt werden kann, finden Sie unter Nichtflüchtige Volumes.
- Da das Quellsicherungslaufwerk auf dem Zieldatenbankcluster bereitgestellt ist, wird die Datei
pgBackRest.confunverändert wiederverwendet. - Sie müssen als Nutzer
postgresin 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 ermitteln. In diesem Beispiel sind alle Sicherungslaufwerke nichtflüchtige Compute Engine-Laufwerke, auf die über die Laufwerk-Handler-ID von Compute Engine-VMs zugegriffen werden kann.
Stellen Sie eine Verbindung zum Zieldatenbankcluster her, um den PVC-Namen zu ermitteln:
kubectl get pvc -n DB_CLUSTER_NAMESPACE | grep DB_CLUSTER_NAME | grep backuprepodiskErsetzen Sie Folgendes:
DB_CLUSTER_NAMESPACE: der Kubernetes-Namespace für diesen Sicherungsplan. Er muss mit dem Namespace des Datenbankclusters übereinstimmen.DB_CLUSTER_NAME: der Name dieses Datenbankclusters, z. B.my-db-cluster.
Hier ist eine Beispielantwort:
backuprepodisk-my-db-cluster-br-0 Bound pvc-36d8f05d-ef1a-4750-ac01-9bb330c15b3a 10Gi RWO standard-rwo 5d21hVerwenden Sie den PVC-Namen des Sicherungslaufwerks aus dem vorherigen Schritt, z. B.
backuprepodisk-my-db-cluster-br-0, um den zugrunde liegenden PV-Namen und den nichtflüchtigen Speicher-Handler der Compute Engine 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.backuprepodisk-my-db-cluster-br-0.
Exportieren Sie die Konfigurationen basierend auf dem PV-Namen als Variablen, die in den folgenden Abschnitten verwendet werden:
export DISK_SIZE=$(kubectl get pv/PV_NAME -o jsonpath="{.spec.capacity.storage}") export FS_TYPE=$(kubectl get pv/PV_NAME -o jsonpath="{.spec.csi.fsType}") export VOLUME_HANDLER=$(kubectl get pv/PV_NAME -o jsonpath="{.spec.csi.volumeHandle}") export STORAGE_CLASS=$(kubectl get pv/PV_NAME -o jsonpath="{.spec.storageClassName}")Ersetzen Sie Folgendes:
PV_NAME: der PV-Name des Sicherungslaufwerks aus der Antwort im vorherigen Schritt.
Nichtflüchtige Volume-Ressource im Zieldatenbankcluster erstellen
Erstellen Sie mit dem Namen des Laufwerk-Handlers eine PersistentVolume-Ressource.
Erstellen Sie im Zieldatenbankcluster die Manifestdatei
PersistentVolume:apiVersion: v1 kind: PersistentVolume metadata: name: backupdisk spec: storageClassName: "${STORAGE_CLASS}" capacity: storage: "${DISK_SIZE}" accessModes: - ReadWriteOnce csi: driver: pd.csi.storage.gke.io volumeHandle: "${VOLUME_HANDLER}" fsType: "${FS_TYPE}"Wenden Sie die Manifestdatei an:
kubectl apply -f PV_FILENAMEErsetzen Sie Folgendes:
- PV_FILENAME: der Name der
PersistentVolume-Manifestdatei, die Sie im vorherigen Schritt erstellt haben.
- PV_FILENAME: der Name der
Zieldatenbankcluster erstellen
Erstellen Sie einen Datenbankcluster, indem Sie den Parameter livenessProbe vorübergehend deaktivieren, während die Wiederherstellung abgeschlossen wird.
Erstellen Sie die Manifestdatei
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: memory: 100Gi cpu: 10 disks: - name: DataDisk size: 40Gi - name: BackupDisk size: ${DISK_SIZE} storageClass: ${STORAGE_CLASS} volumeName: backupdiskErsetzen Sie Folgendes:
DB_CLUSTER_NAME: der Name dieses Datenbankclusters, z. B.my-db-cluster.ENCODED_PASSWORD: Das Datenbank-Anmeldepasswort für die Standardnutzerrollepostgres, codiert als Base64-String, z. B.Q2hhbmdlTWUxMjM=fürChangeMe123.
Wenden Sie die Manifestdatei an:
kubectl apply -f DBCLUSTER_FILENAMEErsetzen Sie Folgendes:
- DBCLUSTER_FILENAME: der Name der
DBCluster-Manifestdatei, die Sie im vorherigen Schritt erstellt haben.
- DBCLUSTER_FILENAME: der Name der
Prüfen Sie mit dem Befehl kubectl describe, ob die Datenbankclusterressource den Status READY hat.
Quellsicherungen im Zieldatenbankcluster prüfen
Führen Sie pgBackRest-Befehle aus, um zu prüfen, ob auf die Sicherungen des Quelldatenbankclusters auf dem Zieldatenbankcluster zugegriffen werden kann.
Suchen Sie in Ihrem Zieldatenbankcluster nach den Pod-Details des Datenbankclusters:
kubectl get pod -l "alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME, alloydbomni.internal.dbadmin.goog/task-type=database"Die Antwort enthält den Namen des Cluster-Datenbank-Pods.
Melden Sie sich im Datenbank-Pod an:
kubectl exec -ti DATABASE_POD_NAME -- /bin/bashErsetzen Sie Folgendes:
- DATABASE_POD_NAME : der Name des Datenbankcluster-Pods aus dem vorherigen Schritt.
Beenden Sie den Pod, bevor Sie die Konfigurationsdatei
pgBackRestaktualisieren:supervisorctl.par stop postgresAktualisieren Sie die Konfigurationsdatei
pgBackRest:cp /backup/pgbackrest.conf pgbackrest.conf.bak rm /backup/pgbackrest.conf cat << EOF > /backup/pgbackrest.conf [db] pg1-path=/mnt/disks/pgsql/data pg1-socket-path=/tmp pg1-user=pgbackrest[global] log-path=/backup/logs log-level-file=info EOFPrüfen Sie die Quellsicherungen im Datenbankcluster-Pod:
pgbackrest --config-path=/backup --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 von einem bestimmten Zeitpunkt innerhalb des Wiederherstellungszeitraums wiederherzustellen.
Sicherung im Zieldatenbankcluster wiederherstellen
Nachdem Sie die Sicherung oder den Zeitpunkt ermittelt haben, zu dem Sie wiederherstellen möchten, führen Sie pgBackRest-Befehle in Ihrem Zieldatenbankcluster aus. Weitere Informationen zu diesen Befehlen finden Sie unter Befehl „restore“.
Im Folgenden finden Sie einige Beispiele für pgBackRest-Wiederherstellungsbefehle:
Aus einer Sicherung wiederherstellen
pgbackrest --config-path=/backup --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=/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
Pod neu starten
Nachdem der Wiederherstellungsbefehl erfolgreich abgeschlossen wurde, können Sie den postgres-Vorgang starten.
supervisorctl.par start postgresNachdem der postgres-Prozess gestartet wurde, können Sie eine Verbindung zur primären Instanz herstellen und Abfragen ausführen, um zu prüfen, ob die Daten aus dem Back-up wiederhergestellt wurden. Weitere Informationen finden Sie unter Verbindung zu AlloyDB Omni herstellen, das auf Kubernetes ausgeführt wird.