Diese Seite wurde von der Cloud Translation API übersetzt.

Datenbankcluster in Kubernetes mit einer Cloud Storage-Sicherung klonen

Wählen Sie eine Dokumentationsversion aus:

Auf dieser Seite wird beschrieben, wie Sie einen Datenbankcluster in Kubernetes mit einer Cloud Storage-Sicherung eines AlloyDB Omni-Datenbankclusters klonen.

Im folgenden Workflow werden die Schritte zum Klonen beschrieben:

Erstellen Sie die Manifestdatei DBCluster und wenden Sie sie auf den Zieldatenbankcluster an, wobei der Parameter livenessProbe deaktiviert ist.
Erstellen und konfigurieren Sie die Datei pgbackrest.conf, um auf die Cloud Storage-Sicherung zuzugreifen.
Mit pgBackRest-Befehlen können Sie prüfen, ob Sie auf Quellsicherungen zugreifen können.
Verwenden Sie pgBackRest-Befehle, um die Sicherung im Zieldatenbankcluster wiederherzustellen.

Hinweise

Sie benötigen Zugriff auf den vollständigen Pfad des Cloud Storage-Bucket, in dem die Sicherung Ihres Quelldatenbankclusters gespeichert ist. Dies ist derselbe Pfad, den Sie beim Erstellen der BackupPlan-Ressource für Ihren Quelldatenbankcluster verwendet haben.
Erstellen Sie einen Ziel-AlloyDB Omni-Datenbankcluster. Weitere Informationen zur Installation von AlloyDB Omni in Kubernetes finden Sie unter Datenbankcluster erstellen.
Achten Sie darauf, dass Sie als Nutzer postgres in der Datenbank angemeldet sind.

Datenbankcluster in einem Zieldatenbankcluster erstellen

Erstellen Sie einen Datenbankcluster, indem Sie den Parameter livenessProbe vorübergehend deaktivieren. Konfigurieren Sie nach Abschluss der Wiederherstellung den Parameter livenessProbe neu.

Erstellen Sie die Manifestdatei für die DBCluster-Ressource:

  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:
        cpu: CPU_COUNT
        memory: MEMORY_SIZE
        disks:
        - name: DataDisk
          size: DISK_SIZE
          storageClass: standard

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.
CPU_COUNT: Die Anzahl der CPUs, die für jede Datenbankinstanz in diesem Datenbankcluster verfügbar sind.
MEMORY_SIZE: die Größe des Arbeitsspeichers pro Datenbankinstanz dieses Datenbankclusters. Wir empfehlen, diesen Wert auf 8 GB pro CPU festzulegen. Wenn Sie beispielsweise cpu weiter oben in diesem Manifest auf 2 gesetzt haben, empfehlen wir, memory auf 16Gi zu setzen.
DISK_SIZE: die Laufwerkgröße pro Datenbankinstanz, z. B. 10Gi.

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 Datenbankclusterressource im Status READY befindet.

`pgBackRest`-Datei konfigurieren

Konfigurieren Sie die Datei pgBackRest, damit der Zieldatenbankcluster auf den Cloud Storage-Bucket zugreifen kann, in dem sich die Quellsicherungen befinden.

Suchen Sie in Ihrem Zieldatenbankcluster nach den Pod-Details des Datenbankclusters:

  kubectl get pod -l "alloydbomni.internal.dbadmin.goog/dbcluster=<var>DB_CLUSTER_NAME</var>, alloydbomni.internal.dbadmin.goog/task-type=database"

Die Antwort enthält den Namen des Clusterdatenbank-Pods.

Melden Sie sich beim 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
```
Erstellen Sie eine pgBackRest-Konfigurationsdatei, um auf in Cloud Storage gespeicherte Sicherungen zuzugreifen:
```
  cat << EOF > /backup/pgbackrest.conf
  [db]
  pg1-path=/mnt/disks/pgsql/data
  pg1-socket-path=/tmp
  pg1-user=pgbackrest
  [global]
  log-path=/obs/pgbackrest
  log-level-file=info
  repo1-type=gcs
  repo1-gcs-bucket=GCS_SOURCE_BACKUP_BUCKET_NAME
  repo1-path=GCS_SOURCE_BACKUP_BUCKET_PATH
  repo1-storage-ca-file=/etc/ssl/certs/ca-certificates.crt
  repo1-retention-full=9999999
  repo1-gcs-key-type=auto
```
Ersetzen Sie Folgendes:
- GCS_SOURCE_BACKUP_BUCKET_NAME: Der Name des Cloud Storage-Buckets, den Sie beim Erstellen der BackupPlan-Ressourcenmanifestdatei für den Quelldatenbankcluster erstellt haben. Dies ist nicht die vollständige URL zum Bucket. Stellen Sie dem Bucket-Namen nicht gs:// voran.
- GCS_SOURCE_BACKUP_BUCKET_PATH: Der Pfad des Verzeichnisses, in das der AlloyDB Omni-Operator Sicherungen schreibt, innerhalb des Cloud Storage-Bucket für den Quelldatenbankcluster. Der Pfad muss absolut sein und mit / beginnen.
repo1-gcs-key-type ist auf auto festgelegt, um das Dienstkonto der Instanz zu verwenden. Weitere Informationen zu anderen Optionen finden Sie unter GCS Repository Key Type Option.

Quellsicherungen im Zieldatenbankcluster prüfen

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

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-Befehl.

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

Datenbankcluster konfigurieren

Nachdem Sie einen Datenbankcluster geklont haben, konfigurieren Sie die Spezifikationen des Datenbankclusters. Vergessen Sie vor allem nicht, den Parameter livenessProbe mit dem folgenden Befehl zu aktivieren:

    kubectl patch dbcluster DBCLUSTER_FILENAME --type merge -p '{"spec":{"primarySpec":{"availabilityOptions":{"livenessProbe":"Enabled"}}}}'

Nächste Schritte

Datenbankcluster in Kubernetes mit einer lokalen Sicherung klonen

Datenbankcluster in Kubernetes mit einer Cloud Storage-Sicherung klonen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.