Mit der datacenterübergreifenden Replikation arbeiten

Kubernetes

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

2. Wenn Sie die datenbankü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 über ausreichend Write-Ahead Logging (WAL)-Speicherplatz verfügen, um die für die Replikation in den sekundären Cluster erforderlichen WAL-Dateien aufzunehmen. Legen Sie die WAL-Größe für Ihren primären AlloyDB Omni-Datenbankcluster fest, indem Sie den Abschnitt „spec“ des Datenbankcluster-Manifests 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 der bisherigen 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 MB 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 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, die das WAL während automatischer Datenbank-Prüfpunkte erreichen darf. Der Standardwert ist 1.504 MB. Dieser Wert muss höher als der wal_keep_size-Wert sein.

3. Wenn Sie die Replikation in Ihrem primären Datenbankcluster aktivieren möchten, wenden Sie ein Manifest an, 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 von 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.

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

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. Achten Sie darauf, dass 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“ des Manifests Folgendes hinzu:

    allowExternalIncomingTraffic: true
   

9. Wenn Sie die Replikation für Ihren sekundären Datenbankcluster aktivieren möchten, wenden Sie ein Manifest an, 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.

Kubernetes

kubectl get dbcluster SECONDARY_DB_CLUSTER_NAME
kubectl get replication SECONDARY_REPLICATION_NAME

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 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. Prüfen Sie, ob das Ergebnis 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 committet 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;'

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

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 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. Prüfen Sie, ob das Ergebnis einen Verzögerungswert von 0 enthält.

   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;'

Kubernetes

1. Wenn Sie Ihren sekundären AlloyDB Omni-Datenbankcluster in einen primären Datenbankcluster umwandeln möchten, aktualisieren Sie das zugehörige 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

   Die 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 zugehörige 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“ lautet.

4. So prüfen Sie den Replikationsstatus:

   kubectl get replication REPLICATION_NAME