Mit der datacenterübergreifenden Replikation arbeiten

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

Eine konzeptionelle Übersicht über die datacenterübergreifende Replikation finden Sie unter Datencenterübergreifende Replikation.

Hinweise

  • 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

  1. Achten Sie darauf, dass die externe Konnektivität für Ihren primären AlloyDB Omni-Datenbankcluster aktiviert ist. Wenn die externe Konnektivität nicht aktiviert ist, fügen Sie dem Abschnitt „spec“ des Manifests des Datenbankclusters Folgendes hinzu:

      kind: DBCluster
  spec:
   allowExternalIncomingTraffic: true

  2. Um die Replikation in Ihrem primären Datenbankcluster zu aktivieren, wenden Sie ein Manifest ähnlich dem folgenden 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, das 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.

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

    Eine Beispielausgabe sieht in etwa so aus:

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

  4. Notieren Sie sich die Ausgabe, da Sie sie im nächsten Schritt benötigen, um die Replikation im sekundären Datenbankcluster zu aktivieren.

  5. Erstellen Sie einen AlloyDB Omni-Cluster in Ihrem Kubernetes-Cluster im sekundären Rechenzentrum mit derselben Konfiguration wie Ihr primärer Datenbankcluster.

  6. Achten Sie darauf, dass die externe Konnektivität in Ihrem sekundären AlloyDB Omni-Datenbankcluster aktiviert ist.

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

     allowExternalIncomingTraffic: true

  8. Um die Replikation in Ihrem sekundären Datenbankcluster zu aktivieren, wenden Sie ein Manifest ähnlich dem folgenden 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, das 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 zur 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 Replikationsslots 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 eine Streamingreplikation vom primären Datenbankcluster verwendet, ist der Replikationsstatus „Bereit“ und „Integritätsprüfung bestanden“.

Sekundären Datenbankcluster hochstufen

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

Kubernetes

  • Prüfen Sie den Replikationsstatus des sekundären Datenbankclusters, um sicherzustellen, dass er bereit und fehlerfrei ist.

    kubectl get replication SECONDARY_REPLICATION_NAME

  • Beenden Sie alle Schreibvorgänge an den primären Datenbankcluster. Führen Sie die folgende Abfrage auf Ihrem primären Datenbankcluster aus, um die Replikationsverzögerung der sekundären Datenbank zu prüfen. Prüfen Sie, ob das Ergebnis eine minimale Verzögerung aufweist.

    Ein Wert von 0 ist ideal. Wenn die Verzögerung größer als 0 ist, können Sie den sekundären Datenbankcluster trotzdem zum primären Cluster machen. Es besteht jedoch das Risiko, dass einige aktuelle Transaktionen verloren gehen, die bereits im primären Datenbankcluster verbindlich gemacht 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 in einen primären Datenbankcluster umwandeln möchten, aktualisieren Sie das Feld control 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

Switchover durchführen

Bevor Sie einen Switchover ausführen, prüfen Sie, ob die primären und sekundären Datenbankcluster, die zu den beiden Rechenzentren gehören, online sind und sich in einem fehlerfreien Zustand befinden.

Um die Datenkonsistenz Ihrer primären und sekundären Datenbankcluster während der Umstellung zu gewährleisten, 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 bereit und fehlerfrei ist.

    kubectl get replication SECONDARY_REPLICATION_NAME

  • Beenden Sie alle Schreibvorgänge an den primären Datenbankcluster. Führen Sie die folgende Abfrage auf Ihrem primären Datenbankcluster aus, um die Replikationsverzögerung der sekundären Datenbank zu prüfen. Prüfen Sie, ob das Ergebnis einen Verzögerungswert von 0 anzeigt.

     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 Switchover durch:

Kubernetes

  1. Wenn Sie Ihren sekundären AlloyDB Omni-Datenbankcluster in einen primären Datenbankcluster konvertieren möchten, aktualisieren Sie das Replikationsmanifest in Ihrem Kubernetes-Cluster im sekundären Rechenzentrum so:

       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.

  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

    Eine Beispielausgabe sieht in etwa 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 das Replikationsmanifest in Ihrem Kubernetes-Cluster im primären Rechenzentrum so:

        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“ lautet.

  4. So prüfen Sie den Replikationsstatus:

    kubectl get replication REPLICATION_NAME