Auf dieser Seite wird AlloyDB Omni-Version 15.7.1 mit der Bereitstellungsoption Container dokumentiert. Wählen Sie eine andere Bereitstellungsoption aus.

Diese Seite wurde von der Cloud Translation API übersetzt.

Mit der datacenterübergreifenden Replikation arbeiten

Wählen Sie eine Dokumentationsversion aus:

Auf dieser Seite wird beschrieben, wie Sie die rechenzentrumsübergreifende Replikation verwenden, indem Sie sekundäre Datenbankcluster in Kubernetes erstellen und damit arbeiten.

Eine konzeptionelle Übersicht über die rechenzentrumsübergreifende Replikation finden Sie unter Informationen zur rechenzentrumsübergreifenden Replikation.

Hinweis

Installieren Sie den AlloyDB Omni-Operator in Version 1.1.0 oder höher, um AlloyDB Omni in einem Kubernetes-Cluster im primären Rechenzentrum und in einem Kubernetes-Cluster im sekundären Rechenzentrum bereitzustellen.
Erstellen Sie einen AlloyDB Omni-Datenbankcluster im Kubernetes-Cluster im primären Rechenzentrum.

Sekundären Datenbankcluster erstellen

So erstellen Sie einen sekundären AlloyDB Omni-Datenbankcluster und aktivieren die Replikation von Ihrem primären Datenbankcluster:

Kubernetes

Achten Sie darauf, dass die externe Verbindung in Ihrem primären AlloyDB Omni-Datenbankcluster aktiviert ist. Wenn die externe Konnektivität nicht aktiviert ist, fügen Sie dem Abschnitt „spec“ des Datenbankclustermanifests Folgendes hinzu:
```
  kind: DBCluster
  spec:
   allowExternalIncomingTraffic: true
```
Wenn Sie die rechenzentrumsübergreifende Replikation mit einem primären Datenbankcluster verwenden möchten, für den HA aktiviert ist, müssen Sie dafür sorgen, dass sowohl der primäre als auch der Standby-Datenbankserver in Ihrem primären Datenbankcluster ausreichend WAL-Speicherplatz (Write-Ahead Logging) hat, um die WAL-Dateien aufzunehmen, die für die Replikation in den sekundären Cluster erforderlich sind. Legen Sie die WAL-Größe für Ihren primären AlloyDB Omni-Datenbankcluster fest, indem Sie den Abschnitt „spec“ des Datenbankclustermanifests festlegen:
```
  kind: DBCluster
  spec:
    primarySpec:
      parameters:
        wal_keep_size: WAL_KEEP_SIZE
        max_wal_size: MAX_WAL_SIZE
```
Ersetzen Sie Folgendes:
- WAL_KEEP_SIZE: Die Mindestgröße bisheriger WAL-Dateien, die im WAL-Verzeichnis gespeichert sind, falls ein sekundärer Server sie für die Streaming-Replikation abrufen muss. Wenn ein mit dem primären Server verbundener sekundärer Server um mehr als wal_keep_size Megabyte zurückbleibt, kann es sein, dass der primäre Server ein WAL-Segment entfernt, das der sekundäre Server benötigt. In diesem Fall wird die Replikationsverbindung beendet. Auch Downstream-Verbindungen schlagen dann irgendwann fehl. Legen Sie WAL_KEEP_SIZE auf einen Wert fest, der Ihre Arbeitslastanforderungen unterstützt. Berücksichtigen Sie dabei die WAL-Generierungsrate, die Eigenschaften des Replikationsnetzwerks und die Replikationsverzögerung zwischen den Rechenzentren, in denen Ihre primären und sekundären Datenbankcluster bereitgestellt werden. Der Standardwert ist 100 MB.
- MAX_WAL_SIZE: Die maximale Größe, auf die das WAL während automatischer Datenbank-Prüfpunkte wachsen darf. Der Standardwert ist 1504 MB. Dieser Wert muss so festgelegt werden, dass er höher ist als der wal_keep_size-Wert.
Wenn Sie die Replikation in Ihrem primären Datenbankcluster aktivieren möchten, wenden Sie ein Manifest, das dem folgenden ähnelt, auf Ihren Kubernetes-Cluster im primären Rechenzentrum an:
```
apiVersion: v1
kind: Secret
metadata:
 name: ha-rep-pw-DB_CLUSTER_NAME
type: Opaque
data:
 rep-user-pw: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
 name: REPLICATION_NAME
spec:
 dbcluster:
   name: DB_CLUSTER_NAME
 upstream:
   password:
     name: ha-rep-pw-DB_CLUSTER_NAME
```
Ersetzen Sie Folgendes:
- DB_CLUSTER_NAME: Der Name des Datenbankclusters, z. B. dbc-1.
- ENCODED_PASSWORD: Das Passwort für den Datenbanknutzer, der für die Replikation aus sekundären Datenbanken verwendet werden soll, codiert als Base64-String, z. B. Q2hhbmdlTWUxMjM= for ChangeMe123. Der Standardwert ist alloydbreplica.
- REPLICATION_NAME: Der Name der Replikation, z. B. replication-1.
Warten Sie, bis der Replikationsstatus „bereit“ lautet.

Hinweis: Wenn auf dem Slot keine aktive Replikation erfolgt, wird der Replikationsstatus als „bereit“, aber nicht als „fehlerfrei“ angezeigt. Der Status „fehlerhaft“ ist zu erwarten, wenn Sie den sekundären Datenbankcluster noch nicht eingerichtet haben.

Führen Sie den folgenden Befehl aus, um die Upstream-Verbindungsinformationen abzurufen, die zum Konfigurieren der Replikation im sekundären Datenbankcluster verwendet werden:

  kubectl get replication REPLICATION_NAME
  kubectl get replication REPLICATION_NAME -o json | jq .status.upstream

Die Beispielausgabe sieht dann ungefähr so aus:

  {
   "host": "35.230.32.36",
   "password": {
     "name": "ha-rep-pw-dbc-1"
   },
   "port": 5432,
   "replicationSlotName": "dbc_1_replication_1",
   "username": "alloydbreplica"
  }

Notieren Sie sich die Ausgabe, da Sie sie im nächsten Schritt benötigen, um die Replikation im sekundären Datenbankcluster zu aktivieren.
Erstellen Sie einen AlloyDB Omni-Cluster in Ihrem Kubernetes-Cluster im sekundären Rechenzentrum mit einer Konfiguration, die mit der Ihres primären Datenbankclusters identisch ist.
Achten Sie darauf, dass die externe Verbindung für Ihren sekundären AlloyDB Omni-Datenbankcluster aktiviert ist.
Wenn die externe Konnektivität nicht aktiviert ist, fügen Sie dem Abschnitt „spec“ seines Manifests Folgendes hinzu:
```
 allowExternalIncomingTraffic: true
```
Wenn Sie die Replikation für Ihren sekundären Datenbankcluster aktivieren möchten, wenden Sie ein Manifest, das dem folgenden ähnelt, auf Ihren Kubernetes-Cluster im sekundären Rechenzentrum an:
```
  apiVersion: v1
  kind: Secret
  metadata:
    name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
  type: Opaque
  data:
    rep-user-pw: "ENCODED_PASSWORD"
  ---
  apiVersion: alloydbomni.dbadmin.goog/v1
  kind: Replication
  metadata:
    name: SECONDARY_REPLICATION_NAME
  spec:
    dbcluster:
      name: SECONDARY_DB_CLUSTER_NAME
    downstream:
      host: PRIMARY_HOST
      port: PRIMARY_PORT
      username: alloydbreplica
      password:
        name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
      replicationSlotName: PRIMARY_REPLICATION_SLOT
      control: setup
```
Ersetzen Sie Folgendes:
- SECONDARY_DB_CLUSTER_NAME: Der Name des sekundären Datenbankclusters, z. B. dbc-2.
- ENCODED_PASSWORD: Das Passwort für den Datenbanknutzer, der für die Replikation des primären Datenbankclusters verwendet werden soll, codiert als Base64-String, z. B. Q2hhbmdlTWUxMjM= for ChangeMe123. Der Standardwert ist alloydbreplica.
- SECONDARY_REPLICATION_NAME: Der Name der Replikation, z. B. replication-2.
- PRIMARY_HOST: Der Verbindungsendpunkt des primären Datenbankclusters aus der Ausgabe in Schritt 3, auf den die sekundäre Datenbank für die Replikation zugreifen kann.
- PRIMARY_PORT: Der Verbindungsport des primären Datenbankclusters aus der Ausgabe in Schritt 3, auf den die sekundäre Datenbank für die Replikation zugreifen kann.
- PRIMARY_REPLICATION_SLOT: Der Name des Replikations-Slots im primären Datenbankcluster aus der Ausgabe in Schritt 3, den die sekundäre Datenbank für die Replikation verwenden kann.

Replikation im sekundären Datenbankcluster ansehen

Führen Sie die folgenden Befehle aus, um detaillierte Informationen zu einem sekundären AlloyDB Omni-Datenbankcluster und seinem Replikationsstatus aufzurufen:

Kubernetes

kubectl get dbcluster SECONDARY_DB_CLUSTER_NAME
kubectl get replication SECONDARY_REPLICATION_NAME

Wenn der sekundäre Datenbankcluster erfolgreich eingerichtet wurde und die Streamingreplikation vom primären Datenbankcluster erfolgt, ist der Replikationsstatus sowohl „bereit“ als auch „fehlerfrei“.

Sekundären Datenbankcluster hochstufen

Bevor Sie einen sekundären Datenbankcluster hochstufen, führen Sie die folgenden Schritte aus, um zu prüfen, ob der sekundäre Datenbankcluster alle vom primären Datenbankcluster empfangenen Transaktionen angewendet hat:

Kubernetes

Prüfen Sie den Replikationsstatus des sekundären Datenbankclusters, um sicherzustellen, dass er sowohl „bereit“ als auch „fehlerfrei“ ist.
```
kubectl get replication SECONDARY_REPLICATION_NAME
```
Beenden Sie alle Schreibvorgänge in den primären Datenbankcluster. Führen Sie die folgende Abfrage für den primären Datenbankcluster aus, um die Replikationsverzögerung der sekundären Datenbank zu prüfen. Bestätigen Sie, dass das Ergebnis nur eine minimale Verzögerung aufweist.

Ein Verzögerungswert von 0 ist ideal. Wenn die Verzögerung größer als 0 ist, können Sie den sekundären Datenbankcluster trotzdem hochstufen. Dabei besteht jedoch das Risiko, dass einige der letzten Transaktionen verloren gehen, die bereits im primären Datenbankcluster mit einem Commit übergeben wurden.
```
 psql -h PRIMARY_HOST -U postgres -d postgres -c 'SELECT application_name, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag FROM pg_stat_replication;'
```

Wenn Sie einen sekundären Datenbankcluster zu einem primären Datenbankcluster hochstufen möchten, aktualisieren Sie das Feld Steuerung des Replikationsmanifests des sekundären Datenbankclusters auf promote und wenden Sie es auf Ihren Kubernetes-Cluster im sekundären Rechenzentrum an.

Kubernetes

    apiVersion: v1
    kind: Secret
    metadata:
      name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
    type: Opaque
    data:
      rep-user-pw: "ENCODED_PASSWORD"
    ---
    apiVersion: alloydbomni.dbadmin.goog/v1
    kind: Replication
    metadata:
      name: SECONDARY_REPLICATION_NAME
    spec:
      dbcluster:
        name: SECONDARY_DB_CLUSTER_NAME
      downstream:
        host: PRIMARY_HOST
        port: PRIMARY_PORT
        username: alloydbreplica
        password:
          name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
        replicationSlotName: PRIMARY_REPLICATION_SLOT
        control: promote

Wechsel durchführen

Prüfen Sie, bevor Sie einen Wechsel durchführen, ob die primären und sekundären Datenbankcluster, die zu beiden Rechenzentren gehören, online sind und ob die Datenbankcluster in einem fehlerfreien Zustand sind.

Damit die Datenkonsistenz in Ihrem primären und sekundären Datenbankcluster während des Wechsels gewährleistet ist, führen Sie die folgenden Schritte aus, um zu prüfen, ob der sekundäre Datenbankcluster alle vom primären Datenbankcluster empfangenen Transaktionen angewendet hat:

Kubernetes

Prüfen Sie den Replikationsstatus des sekundären Datenbankclusters, um sicherzustellen, dass er sowohl „bereit“ als auch „fehlerfrei“ ist.
```
kubectl get replication SECONDARY_REPLICATION_NAME
```
Beenden Sie alle Schreibvorgänge in den primären Datenbankcluster. Führen Sie die folgende Abfrage für den primären Datenbankcluster aus, um die Replikationsverzögerung der sekundären Datenbank zu prüfen. Bestätigen Sie, dass das Ergebnis einen Verzögerungswert von 0 aufweist.
```
 psql -h PRIMARY_HOST -U postgres -d postgres -c 'SELECT application_name, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag FROM pg_stat_replication;'
```

So führen Sie einen Wechsel durch:

Kubernetes

Wenn Sie Ihren sekundären AlloyDB Omni-Datenbankcluster in einen primären Datenbankcluster umwandeln möchten, aktualisieren Sie sein Replikationsmanifest in Ihrem Kubernetes-Cluster im sekundären Rechenzentrum folgendermaßen:

   apiVersion: v1
   kind: Secret
   metadata:
    name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
   type: Opaque
   data:
     rep-user-pw: "ENCODED_PASSWORD"
   ---
   apiVersion: alloydbomni.dbadmin.goog/v1
   kind: Replication
   metadata:
    name: SECONDARY_REPLICATION_NAME
   spec:
    dbcluster:
       name: SECONDARY_DB_CLUSTER_NAME
     upstream:
       password:
         name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME

Warten Sie, bis der Replikationsstatus „bereit“ lautet.

Führen Sie den folgenden Befehl aus, um die Upstream-Verbindungsinformationen für die Replikation abzurufen:

kubectl get replication SECONDARY_REPLICATION_NAME
kubectl get replication SECONDARY_REPLICATION_NAME -o json | jq .status.upstream

Die Beispielausgabe sieht dann ungefähr so aus:

 {
   "host": "34.23.207.137",
   "password": {
     "name": "ha-rep-pw-dbc-2"
   },
   "port": 5432,
   "replicationSlotName": "dbc_2_replication_2",
   "username": "alloydbreplica"
 }

Wenn Sie Ihren primären AlloyDB Omni-Datenbankcluster in einen sekundären Datenbankcluster umwandeln möchten, aktualisieren Sie sein Replikationsmanifest in Ihrem Kubernetes-Cluster im primären Rechenzentrum. Das Manifest sollte in etwa so aussehen:

    apiVersion: v1
    kind: Secret
    metadata:
     name: ha-rep-pw-DB_CLUSTER_NAME
    type: Opaque
    data:
      rep-user-pw: "ENCODED_PASSWORD"
    ---
    apiVersion: alloydbomni.dbadmin.goog/v1
    kind: Replication
    metadata:
      name: REPLICATION_NAME
    spec:
      dbcluster:
        name: DB_CLUSTER_NAME
      downstream:
        host: SECONDARY_HOST
        port: SECONDARY_PORT
        username: alloydbreplica
        password:
          name: ha-rep-pw-DB_CLUSTER_NAME
        replicationSlotName: SECONDARY_REPLICATION_SLOT
       control: rewind

Warten Sie, bis der Replikationsstatus „bereit“ und „fehlerfrei“ ist.

So prüfen Sie den Replikationsstatus:

kubectl get replication REPLICATION_NAME

Mit der datacenterübergreifenden Replikation arbeiten Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Hinweis

Sekundären Datenbankcluster erstellen

Kubernetes

Replikation im sekundären Datenbankcluster ansehen

Kubernetes

Sekundären Datenbankcluster hochstufen

Kubernetes

Kubernetes

Wechsel durchführen

Kubernetes

Kubernetes

Mit der datacenterübergreifenden Replikation arbeiten