In diesem Dokument wird beschrieben, wie Sie logische Replikationsslots in AlloyDB Omni erstellen. Die logische Replikation in AlloyDB Omni wird verwendet, um bestimmte Datenänderungen kontinuierlich von der Quelldatenbank (Publisher) an andere Datenbanken oder Anwendungen (Abonnenten) zu streamen. Die gestreamten Änderungen können Aktualisierungen, Einfügungen oder Löschungen einzelner Zeilen sein. Abonnenten stellen über einen eindeutigen Replikations-Slot eine Verbindung zum Publisher her, die eine dauerhafte Verbindung gewährleistet. Eine persistente Verbindung behält den Status des Datenstreams bei. Bei einer Unterbrechung wird das Streaming an der Stelle fortgesetzt, an der es unterbrochen wurde.
Weitere Informationen zur logischen Replikation in PostgreSQL finden Sie unter Logische Replikation.
Publisher- und Abonnentencluster konfigurieren
Bevor Sie die Replikationsslots erstellen, müssen Sie den Publisher- und den Abonnentencluster mit aktivierter logischer Replikation erstellen. Der Parameter wal_level
muss in den entsprechenden Manifesten auf logical
festgelegt sein.
Wenn du einen Publisher-Datenbankcluster mit aktivierter logischer Replikation erstellen möchtest, musst du ein DBCluster
-Manifest erstellen und anwenden.
Hier ein Beispiel für ein Publisher-Manifest:
apiVersion: v1
kind: Secret
metadata:
name: db-pw-mydbc
type: Opaque
data:
mydbc: "Q2hhbmdlTWUxMjM="
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
name: mydbc
spec:
databaseVersion: "15.7.0"
spec:
availability:
numberOfStandbys: 1
primarySpec:
parameters:
wal_level: "logical"
adminUser:
passwordRef:
name: db-pw-mydbc
resources:
cpu: 1
memory: 8Gi
disks:
- name: DataDisk
size: 10Gi
Wenn Sie einen Abonnentendatenbankcluster mit aktivierter logischer Replikation erstellen möchten, erstellen und wenden Sie ein DBCluster
-Manifest an.
Hier siehst du ein Beispiel für ein Manifest für Abonnenten:
apiVersion: v1
kind: Secret
metadata:
name: db-pw-subscriber
type: Opaque
data:
subscriber: "Q2hhbmdlTWUxMjM=" #ChangeMe123
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
name: subscriber
spec:
databaseVersion: "15.7.0"
primarySpec:
parameters:
wal_level: "logical"
adminUser:
passwordRef:
name: db-pw-subscriber
resources:
memory: 10Gi
cpu: 1
disks:
- name: DataDisk
size: 40Gi
—
Replikationsslot erstellen
Nachdem Sie die Publisher- und Abonnentencluster erstellt haben, können Sie mit der Ressource Replication
im Publisher-Cluster einen logischen Replikationsslot erstellen. Jede Replication
-Ressource ist einer entsprechenden Datenbankclusterressource zugeordnet. Mit einem Datenbankcluster können mehrere logische Replikationsressourcen verknüpft sein.
Wende das folgende Manifest an, um einen Replikationsslot in deinem Publisher-Cluster zu konfigurieren:
apiVersion: v1
kind: Secret
metadata:
name: USER_PASSWORD_SECRET_NAME
namespace: USER_PASSWORD_SECRET_NAMESPACE
type: Opaque
data:
rep-user-pw: BASE64_ENCODED_PASSWORD
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
name: REPLICATION_NAME
namespace: NAMESPACE
spec:
dbcluster:
name: DB_CLUSTER_NAME
upstream:
logicalReplication:
pluginName: DECODER_PLUGIN
databaseName: DATABASE_NAME
applicationName: APPLICATION_NAME
replicationSlotName: REPLICATION_SLOT_NAME
synchronous: "REPLICATION_MODE"
username: APPLICATION_USER
password:
name: USER_PASSWORD_SECRET_NAME
namespace: USER_PASSWORD_SECRET_NAMESPACE
Ersetzen Sie Folgendes:
- REPLICATION_NAME: ein Name für diese
Replication
-Ressource, z. B.replication-1
. - NAMESPACE: der Kubernetes-Namespace für diese
Replication
-Ressource. Er muss mit dem Namespace des Datenbankclusters übereinstimmen. - DB_CLUSTER_NAME: Der Name Ihres Datenbankclusters, den Sie beim Erstellen zugewiesen haben.
- DECODER_PLUGIN: Legen Sie das Decodierungs-Plug-in fest, das Sie für die logische Replikation verwenden möchten, z. B.
pgoutput
. Weitere Informationen zu verschiedenen Dekodierungs-Plug-ins findest du unter Ausgabe-Plug-ins. - DATABASE_NAME: muss den Namen der Datenbank enthalten, deren Änderungen zum Replikations-Speicherort gestreamt werden sollen. Die Datenbank muss bereits im Publisher-Cluster erstellt worden sein.
- APPLICATION_NAME (optional): Legen Sie den Namen der Anwendung fest, die eine Verbindung zum Replikationsslot herstellen soll. Dieses Feld ist erforderlich, wenn der Streamingmodus auf „Synchron“ gesetzt ist.
- REPLICATION_MODE (optional): Legen Sie für die asynchrone Replikation
false
fest. Wenn Sie die synchrone Replikation aktivieren möchten, aber auf Kosten der Geschwindigkeit, legen Sie diesen Wert auftrue
fest. Wenn nicht explizit festgelegt, ist der Standardwertfalse
. - REPLICATION_SLOT_NAME: Der Name des Replikationsslots, der erstellt und vom Abonnenten verwendet wird.
- REPLICATION_USER (Optional): Der Name des Nutzers, der eine Verbindung zum Replikationsslot herstellt. Wenn Sie den Nutzer für die Replikation festlegen, müssen Sie auch den Namen des Secrets, den Namespace und das Passwort festlegen.
- USER_PASSWORD_SECRET_NAME (optional): Der Name des Kubernetes-Secrets des Anwendungsnutzers. Erforderlich, wenn der Anwendungsnutzer festgelegt ist.
- USER_PASSWORD_SECRET_NAMESPACE (optional): der Namespace, in dem sich das Kubernetes-Secret für den Anwendungsnutzer befindet. Erforderlich, wenn der Anwendungsnutzer festgelegt ist.
- BASE64_ENCODED_PASSWORD (optional): das base64-codierte Passwort des Anwendungsnutzers. Erforderlich, wenn der Anwendungsnutzer festgelegt ist.
Dem Replikationsnutzer Berechtigungen erteilen
So gewähren Sie dem Nutzer für die Replikation im Publisher-Cluster Replikations- und Veröffentlichungsberechtigungen:
Stelle über
psql
eine Verbindung zum primären Pod im Publisher-Cluster her:psql -h IP_ADDRESS -U USERNAME -d DATABASE_NAME
Ersetzen Sie Folgendes:
- IP_ADDRESS: die IP-Adresse des primären Pods des Publisher-Clusters.
- USERNAME: Der Postgres-Nutzer der Datenbank.
- DATABASE_NAME: die Datenbank, die der Abonnent abonnieren möchte.
Erteilen Sie die Berechtigungen:
GRANT SELECT ON ALL TABLES IN SCHEMA public TO REPLICATION_USER; GRANT USAGE ON SCHEMA public TO REPLICATION_USER; ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO REPLICATION_USER;
Publikation und Abo erstellen
Publikation erstellen
So erstellst du eine Publikation im Publisher-Cluster:
Stelle über
psql
eine Verbindung zum primären Pod im Publisher-Cluster her:psql -h IP_ADDRESS -U USERNAME -d DATABASE_NAME
Ersetzen Sie Folgendes:
- IP_ADDRESS: die IP-Adresse des primären Pods des Publisher-Clusters.
- USERNAME: Der Postgres-Nutzer der Datenbank.
- DATABASE_NAME: die Datenbank, die der Abonnent abonnieren möchte.
Erstellen Sie die Publikation mit dem folgenden Befehl:
CREATE PUBLICATION PUBLICATION_NAME; ALTER PUBLICATION PUBLICATION_NAME ADD TABLE TABLE_NAME;
Ersetzen Sie Folgendes:
- PUBLICATION_NAME: Der Name der Publikation, über den der Abonnent ein Abo abschließt.
- TABLE_NAME: die Tabelle, die der Abonnent abonnieren möchte.
Abo erstellen
So erstellst du ein Abo im Abonnentencluster:
Stellen Sie über
psql
eine Verbindung zum primären Pod im Abonnentencluster her:psql -h IP_ADDRESS -U USERNAME -d DATABASE_NAME
Ersetzen Sie Folgendes:
- IP_ADDRESS: die IP-Adresse des primären Pods des Abonnentenclusters.
- USERNAME: der postgres-Nutzer der Datenbank.
- DATABASE_NAME: die Datenbank, die der Abonnent abonnieren möchte.
Erstellen Sie ein Abo mit dem folgenden Befehl:
CREATE SUBSCRIPTION SUBSCRIPTION_NAME CONNECTION 'host=IP_ADDRESS port=PORT user=REPLICATION_USER dbname=DATABASE_NAME password=PASSWORD sslmode=require' PUBLICATION PUBLICATION_NAME WITH (slot_name=REPLICATION_SLOT_NAME, create_slot=false); alter subscription SUBSCRIPTION_NAME refresh publication ;
Ersetzen Sie Folgendes:
- SUBSCRIPTION_NAME: der Name des Abos.
- IP_ADDRESS: die IP-Adresse des primären Pods des Publisher-Clusters.
Alle Änderungen an der Tabelle im Publisher-Cluster werden auf die Tabelle im Abonnentencluster repliziert.
Replikationsslot-Status ansehen
Führen Sie den folgenden Befehl aus, um den Status der Replikationsslots aufzurufen:
kubectl get replication.alloydbomni.dbadmin.goog REPLICATION_NAME -n NAMESPACE -oyaml
Das Feld status
ist zusammen mit anderen Details in der Antwort enthalten:
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
name: REPLICATION_NAME
namespace: NAMESPACE
...
...
status:
conditions:
- lastTransitionTime: "2025-01-25T06:49:25Z"
message: Ready for replication
reason: Ready
status: "True"
type: Ready
- lastTransitionTime: "2025-01-25T06:49:25Z"
message: Replication slot is not being used
reason: Unhealthy
status: "False"
type: Healthy
observedGeneration: 2
upstream:
host: DATABASE_ENDPOINT
password:
name: USER_PASSWORD_SECRET_NAME
namespace: USER_PASSWORD_SECRET_NAMESPACE
port: DATABASE_PORT
replicationSlotName: REPLICATION_SLOT_NAME
username: APPLICATION_USER
Die DATABASE_ENDPOINT
zeigt die IP-Adresse an, die Sie für die Verbindung zur Datenbank verwenden. Der Status TRUE
in der Spalte READY
gibt an, dass der Slot zum Streamen bereit ist. Wenn die Anwendung eine Verbindung zum Replikationsslot herstellt, ändert sich der Status in der Spalte HEALTHY
in TRUE
.
Beschränkungen
Aktualisierungen der Replikationsspalte werden nicht unterstützt. Wenn Sie die Konfiguration aktualisieren möchten, löschen Sie den Replikationsslot und erstellen Sie ihn mit der aktualisierten Konfiguration neu.
Führen Sie den folgenden Befehl aus, um den Replikationsslot zu löschen: kubectl delete replication.alloydbomni.dbadmin.goog REPLICATION_NAME -n NAMESPACE
Sie können den logischen Replikationsslot nur in der Publisher-Datenbank konfigurieren. Die Abonnentenkonfigurationen werden nicht unterstützt.
Wenn der Datenbankcluster, auf den das Replikationsobjekt verweist, für Hochverfügbarkeit konfiguriert ist, wird der logische Replikations-Speicherplatz nach einem Failover auf dem hochgestuften Standby-Server neu erstellt. Nachdem der Replikationsslot neu erstellt wurde, ist die Position des Streams im Slot nicht mehr verfügbar. Alle Anwendungen, die den Stream abonniert haben, müssen sich wieder verbinden und den Stream wiedergeben.