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 AlloyDB Omni Operator 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 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: trueUm 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_NAMEErsetzen 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 istalloydbreplica.REPLICATION_NAME: der Name der Replikation, z. B.replication-1.
Warten Sie, bis der Replikationsstatus „Bereit“ lautet.
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_NAMEkubectl get replication REPLICATION_NAME -o json | jq .status.upstreamEine 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" }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 derselben Konfiguration wie Ihr primärer Datenbankcluster.
Achten Sie darauf, dass die externe Konnektivität in Ihrem sekundären AlloyDB Omni-Datenbankcluster aktiviert ist.
Wenn die externe Konnektivität nicht aktiviert ist, fügen Sie dem Abschnitt „spec“ des Manifests Folgendes hinzu:
allowExternalIncomingTraffic: trueUm 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: setupErsetzen 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 istalloydbreplica.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_NAMEkubectl 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_NAMEBeenden 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_NAMEBeenden 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
0anzeigt.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
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_NAMEWarten 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_NAMEkubectl get replication SECONDARY_REPLICATION_NAME -o json | jq .status.upstreamEine 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" }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: rewindWarten Sie, bis der Replikationsstatus „Bereit“ und „Fehlerfrei“ lautet.
So prüfen Sie den Replikationsstatus:
kubectl get replication REPLICATION_NAME