Mit der rechenzentrumsü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

  • Prüfen Sie, ob Sie eine zuverlässige Netzwerkverbindung mit geringer Latenz zwischen den primären und sekundären Rechenzentren haben. Dies ist für die effektive Funktion der rechenzentrumsübergreifenden Replikation entscheidend.
  • Installieren Sie die aktuelle Version des AlloyDB Omni-Operators, um AlloyDB Omni in einem Kubernetes-Cluster im primären Rechenzentrum und in einem Kubernetes-Cluster im sekundären Rechenzentrum bereitzustellen. Die datenzentrumsübergreifende Replikation wird in AlloyDB Omni-Operator-Version 1.5.0 und höher unterstützt.
  • Erstellen Sie einen AlloyDB Omni-Datenbankcluster im Kubernetes-Cluster im primären Rechenzentrum.
  • Achten Sie darauf, dass die primären und Standby-Datenbankserver in Ihrem primären Datenbankcluster über ausreichend Speicherplatz für Write-Ahead-Logging (WAL) verfügen, um die für die Replikation in den sekundären Cluster erforderlichen WAL-Dateien aufzunehmen. Alle Daten, die noch nicht in den sekundären Cluster repliziert wurden, werden im primären Cluster als WAL-Dateien gespeichert. Je nach Verbindungsgeschwindigkeit zwischen dem primären und dem sekundären Cluster benötigen Sie dafür möglicherweise zusätzlichen Speicherplatz.
  • Beachten Sie die folgenden Informationen zu sekundären Datenbank-Standbys mit Hochverfügbarkeit (Vorabversion): Wenn die Version des AlloyDB Omni-Operators und die Version des Agents der Steuerungsebene 1.7.0 oder höher sind, kann der sekundäre Datenbankcluster Hochverfügbarkeits-Standbys unterstützen.

    Im Gegensatz zu HA-Standby-Instanzen im primären Datenbankcluster sind HA-Standby-Instanzen im sekundären Datenbankcluster asynchron, bis der sekundäre Datenbankcluster zu einer primären Datenbank hochgestuft wird. HA-Stand-bys werden automatisch synchron oder asynchron, wenn die Datenbankclusterrolle während eines Switchovers geändert wird.

Sekundären Datenbankcluster erstellen

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

  1. Prüfen Sie, ob 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:

    ...
spec:
  ...
  allowExternalIncomingTraffic: true

  2. Wenn Sie die rechenzentrumsübergreifende Replikation mit einem primären Datenbankcluster verwenden möchten, für den Hochverfügbarkeit (HA) aktiviert ist, prüfen Sie, ob das Feld replayReplicationSlotsOnStandbys im primären Datenbankcluster aktiviert ist:

    ...
spec:
  ...
  availability:
    ...
    replayReplicationSlotsOnStandbys: true

    Wenn Sie dieses Feld zusammen mit dem im folgenden Schritt erläuterten logReplicationSlots aktivieren, wird der vom sekundären Datenbankcluster verwendete Replikationsslot mit allen HA-Standby-Instanzen synchronisiert. Mit dieser Konfiguration kann die neue primäre Hochverfügbarkeitsinstanz alle WAL-Dateien (Write-Ahead Logging) beibehalten, die nach einem Failover oder Switchover noch nicht vom sekundären Datenbankcluster verarbeitet wurden. So kann der sekundäre Datenbankcluster die Replikation ohne Unterbrechung fortsetzen.

  3. 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
  namespace: DB_CLUSTER_NAMESPACE
type: Opaque
data:
  rep-user-pw: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
  name: REPLICATION_NAME
  namespace: DB_CLUSTER_NAMESPACE
spec:
  dbcluster:
    name: DB_CLUSTER_NAME
  upstream:
    password:
      name: ha-rep-pw-DB_CLUSTER_NAME
    logReplicationSlot: true

    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.
    • LOG_REPLICATION_SLOT: Daten des Replikations-Slots in WAL-Dateien protokollieren. Wenn Sie diese Option aktivieren möchten, setzen Sie den Wert auf true. Der Standardwert ist false.

    Wir empfehlen, die Option logReplicationSlot mit einem primären Datenbankcluster zu aktivieren, für den Hochverfügbarkeit (HA) aktiviert ist. So kann die Replikation nach einem Failover oder Switchover fortgesetzt werden.

    Warten Sie, bis der Replikationsstatus „bereit“ lautet.

  4. 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"
  }
  5. Notieren Sie sich die Ausgabe, da Sie sie im nächsten Schritt benötigen, um die Replikation im sekundären Datenbankcluster zu aktivieren.
  6. 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.
  7. Prüfen, ob die externe Verbindung für Ihren sekundären AlloyDB Omni-Datenbankcluster aktiviert ist

  8. Wenn die externe Konnektivität nicht aktiviert ist, fügen Sie dem Abschnitt „spec“ seines Manifests Folgendes hinzu:

    ...
spec:
  ...
  allowExternalIncomingTraffic: true
  9. 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
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
type: Opaque
data:
  rep-user-pw: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
  name: SECONDARY_REPLICATION_NAME
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
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 aus dem primären Datenbankcluster 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 4, 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 4, 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 4, 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:

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

Wenn Sie einen sekundären Datenbankcluster hochstufen, müssen Sie zuerst prüfen, ob der sekundäre Datenbankcluster alle vom primären Datenbankcluster empfangenen Transaktionen angewendet hat.

  1. Prüfen Sie, ob der Replikationsstatus des sekundären Datenbankclusters sowohl „bereit“ als auch „fehlerfrei“ ist: 
    kubectl get replication SECONDARY_REPLICATION_NAME
  2. Beenden Sie alle Schreibvorgänge in den primären Datenbankcluster. Führen Sie einen Prüfpunkt für den primären Datenbankcluster aus und führen Sie dann 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.
    1. Führen Sie einen Prüfpunkt aus, um den Arbeitsspeicher auf das Laufwerk zu schreiben.
      psql -h PRIMARY_HOST -U postgres -d postgres -c 'CHECKPOINT;'
    2. Prüfen Sie die Replikationsverzögerung. Ein Verzögerungswert von 0 ist optimal. 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;'

  3. Stufen Sie einen sekundären Datenbankcluster zu einem primären Datenbankcluster hoch, indem Sie das Feld control des Replikationsmanifests des sekundären Datenbankclusters auf promote aktualisieren. Wenden Sie dann das aktualisierte Replikationsmanifest auf Ihren Kubernetes-Cluster im sekundären Rechenzentrum an.

    apiVersion: v1
kind: Secret
metadata:
  name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
type: Opaque
data:
  rep-user-pw: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
  name: SECONDARY_REPLICATION_NAME
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
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 in beiden Rechenzentren online sind und sich in einem fehlerfreien Zustand befinden.

So sorgen Sie für Datenkonsistenz zwischen Ihrem primären und sekundären Datenbankcluster und führen einen Wechsel durch:

  1. Prüfen Sie, ob der Replikationsstatus des sekundären Datenbankclusters sowohl „bereit“ als auch „fehlerfrei“ ist: 
    kubectl get replication SECONDARY_REPLICATION_NAME
  2. Beenden Sie alle Schreibvorgänge in den primären Datenbankcluster und führen Sie dann die folgenden Schritte für den primären Datenbankcluster aus:
    1. Führen Sie einen Prüfpunkt aus, um den Speicher auf das Laufwerk zu übertragen: 
      psql -h PRIMARY_HOST -U postgres -d postgres -c 'CHECKPOINT;'
    2. Prüfen Sie die Replikationsverzögerung des sekundären Datenbankclusters und 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;'

  3. So stufen Sie den sekundären Datenbankcluster zu einem primären Datenbankcluster hoch und wandeln den ehemaligen primären Datenbankcluster in einen sekundären Datenbankcluster um:

    1. 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
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
type: Opaque
data:
  rep-user-pw: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
  name: SECONDARY_REPLICATION_NAME
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
spec:
  dbcluster:
    name: SECONDARY_DB_CLUSTER_NAME
  upstream:
    password:
      name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME

      Ersetzen Sie SECONDARY_DB_CLUSTER_NAME durch den Namen Ihres sekundären Datenbankclusters, z. B. dbc-2.

      Warten Sie, bis der Replikationsstatus „bereit“ lautet.

    2. 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"
  }

    3. 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:

      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.

    4. Prüfen Sie den Replikationsstatus:

      kubectl get replication REPLICATION_NAME

Ungeplante Notfallwiederherstellung durchführen

Wenn Ihr primäres Rechenzentrum oder Ihr primärer Datenbankcluster unerwartet nicht mehr verfügbar ist, können Sie ein ungeplantes Failover zur Notfallwiederherstellung durchführen. Stufen Sie dazu den sekundären Datenbankcluster hoch und konfigurieren Sie den ehemaligen primären Datenbankcluster neu, nachdem er wieder online ist:

  1. Stufen Sie Ihren sekundären AlloyDB Omni-Datenbankcluster zu einem primären Datenbankcluster hoch. Aktualisieren Sie das Replikationsmanifest des sekundären Datenbankclusters in Ihrem Kubernetes-Cluster im sekundären Rechenzentrum, wie in Schritt 3a unter Wechsel durchführen beschrieben.
  2. Nachdem das ursprüngliche primäre Rechenzentrum wieder verfügbar ist, wandeln Sie den ehemaligen primären Datenbankcluster in einen sekundären Datenbankcluster um, der vom neuen primären Cluster repliziert wird. Führen Sie die Schritte 3b, 3c und 3d unter Wechsel durchführen aus, wobei Sie Schritt 3c ändern. Legen Sie in Schritt 3c control: setup anstelle von control: rewind fest, um den Cluster über die neue primäre Instanz neu zu initialisieren. Verwenden Sie nicht control: rewind, da der ehemalige primäre Datenbankcluster möglicherweise Änderungen enthält, die vor dem Failover nicht synchronisiert wurden.