Diese Seite wurde von der Cloud Translation API übersetzt.

Datenbankcluster in Kubernetes mithilfe einer lokalen Sicherung klonen

Wählen Sie eine Dokumentationsversion aus:

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 Ziel-Datenbankcluster in Google Kubernetes Engine erstellt wurden und die Sicherungs-Volumes nichtflüchtige Compute Engine-Speicher sind. Außerdem wird davon ausgegangen, dass die nichtflüchtigen Compute Engine-Speicher, die als Sicherung in der Datenbank verwendet werden, nicht von einem anderen Datenbankcluster verwendet werden.

Im folgenden Workflow werden die Schritte zum Klonen beschrieben:

Ermitteln Sie die Informationen zum Sicherungslaufwerk, z. B. den Namen des nichtflüchtigen Volumes und den Handle des nichtflüchtigen Compute Engine-Speichers, für das Sicherungslaufwerk des Quelldatenbankclusters.
Erstellen Sie eine PersistentVolume-Ressource, um auf das Sicherungslaufwerk des Quelldatenbankclusters zuzugreifen und ein vorhandenes Sicherungslaufwerk im Zieldatenbankcluster zu verwenden.
Erstellen Sie die Ressourcenmanifestdatei DBCluster und wenden Sie sie auf den Zieldatenbankcluster an. Der Parameter livenessProbe muss deaktiviert sein und es müssen Informationen zum Sicherungslaufwerk hinzugefügt werden.
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.
Die Sicherungsdisk des Quelldatenbankclusters muss im Zieldatenbankcluster eingebunden werden können. Weitere Informationen zu den Schritten, die Sie ausführen müssen, damit Ihr Laufwerk bereitgestellt werden kann, finden Sie unter PersistentVolumes.
Da das Quellsicherungs-Laufwerk im Zieldatenbankcluster eingebunden ist, wird die Datei pgBackRest.conf unverändert wiederverwendet.
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üchtigen Speicher ermitteln. Im Beispiel sind alle Sicherungslaufwerke nichtflüchtige Compute Engine-Speicher, auf die über den Laufwerk-Handler-Bezeichner auf Compute Engine-VMs zugegriffen werden kann.

Stellen Sie eine Verbindung zu Ihrem Zieldatenbankcluster her, um den PVC-Namen zu ermitteln:
```
 kubectl get pvc -n DB_CLUSTER_NAMESPACE | grep DB_CLUSTER_NAME | grep backupdisk
```
Ersetzen 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 die Beispielantwort.
```
    backupdisk-al-fe8c-my-db-cluster-0   Bound
    pvc-36d8f05d-ef1a-4750-ac01-9bb330c15b3a   10Gi       RWO            standard-rwo   5d21h
```
Verwenden Sie den PVC-Namen des Sicherungslaufwerks aus dem vorherigen Schritt, z. B. backupdisk-al-fe8c-my-db-cluster-0, um den zugrunde liegenden PV-Namen und den Compute Engine-Handler für nichtflüchtige Speicher zu ermitteln:
```
  kubectl get pvc/PVC_NAME -n DB_CLUSTER_NAME -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.

Exportieren Sie die Konfigurationen basierend auf dem PV-Namen als Variablen, die in den folgenden Abschnitten verwendet werden sollen:

  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_FILENAME
```
Ersetzen Sie Folgendes:
- PV_FILENAME: der Name der PersistentVolume-Manifestdatei, die im vorherigen Schritt erstellt wurde.

Ziel-Datenbankcluster erstellen

Erstellen Sie einen Datenbankcluster, indem Sie den Parameter livenessProbe vorübergehend deaktivieren, während der Wiederherstellungsvorgang 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: backupdisk

Ersetzen Sie Folgendes:

DB_CLUSTER_NAME: Der Name dieses Datenbankclusters, z. B. my-db-cluster.
ENCODED_PASSWORD: Das Datenbankanmeldepasswort für die Standardnutzerrolle postgres, codiert als Base64-String, z. B. Q2hhbmdlTWUxMjM= für ChangeMe123.

Wenden Sie die Manifestdatei an:
```
  kubectl apply -f DBCLUSTER_FILENAME
```
Ersetzen Sie Folgendes:
- DBCLUSTER_FILENAME: der Name der DBCluster-Manifestdatei, die im vorherigen Schritt erstellt wurde.

Prüfen Sie mit dem Befehl kubectl describe, ob sich die Datenbankcluster-Ressource im Status READY befindet.

Quellsicherungen im Zieldatenbankcluster überprüfen

Führen Sie pgBackRest-Befehle aus, um zu prüfen, ob die Sicherungen des Quelldatenbankclusters im Zieldatenbankcluster verfügbar sind.

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 Clusterdatenbank-Pods.

Melden Sie sich im Datenbank-Pod an:
```
  kubectl exec -ti DATABASE_POD_NAME  -- /bin/bash
```
Ersetzen Sie Folgendes:
- DATABASE_POD_NAME : Der Name des Datenbankcluster-Pods aus dem vorherigen Schritt.
Beenden Sie den Pod, bevor Sie die Konfigurationsdatei pgBackRest aktualisieren:
```
  supervisorctl.par stop postgres
```

Prüfen Sie die Quellsicherungen im Datenbankcluster-Pod:

pgbackrest --config-path=/backup --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 im Zieldatenbankcluster wiederherstellen

Nachdem Sie die Sicherung oder den Zeitpunkt ermittelt haben, zu dem Sie die Daten wiederherstellen möchten, führen Sie pgBackRest-Befehle in Ihrem Zieldatenbankcluster aus. Weitere Informationen zu diesen Befehlen finden Sie unter Restore Command.

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=info

Von 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-Prozess starten.

supervisorctl.par start postgres

Nachdem 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 Backup wiederhergestellt wurden. Weitere Informationen finden Sie unter Verbindung zu AlloyDB Omni herstellen, das auf Kubernetes ausgeführt wird.

Nächste Schritte

Datenbankcluster in Kubernetes mit einer Cloud Storage-Sicherung klonen