Daten aus PostgreSQL-Datenbanken streamen

Dieser Abschnitt enthält Informationen über:

  • Das Verhalten von Datastream zur Verarbeitung von Daten, die aus einer PostgreSQL-Quelldatenbank abgerufen werden
  • Die von Datastream unterstützten Versionen der PostgreSQL-Datenbank
  • Eine Übersicht über das Einrichten einer PostgreSQL-Quelldatenbank, damit Daten daraus an ein Ziel gestreamt werden können
  • Bekannte Einschränkungen bei Verwendung der PostgreSQL-Datenbank als Quelle

Verhalten

Die PostgreSQL-Quelldatenbank greift auf die logische Decodierung zurück. Bei der logischen Decodierung werden alle Änderungen angezeigt, für die ein Commit in der Datenbank durchgeführt wurde. Diese Änderungen können dann mit einem Ausgabeprogramm in einem nutzerfreundlichen Format verwendet und verarbeitet werden. Datastream verwendet das pgoutput-Plug-in, das das Standard-Plug-in für die logische Decodierung von PostgreSQL für PostgreSQL 10 und höher ist.

  • Es können alle Schemas oder bestimmte Schemas einer bestimmten PostgreSQL-Quelle sowie alle Tabellen des Schemas oder bestimmte Tabellen ausgewählt werden.
  • Alle Verlaufsdaten werden repliziert.
  • Alle Änderungen an der Datenbearbeitungssprache (DML) wie Einfügungen, Aktualisierungen und Löschungen aus den angegebenen Datenbanken und Tabellen werden repliziert.
  • Es werden nur Änderungen repliziert, für die ein Commit durchgeführt wurde.
  • Wenn Sie für eine Tabelle eine REPLICA IDENTITY definieren, behandelt Datastream die angegebenen Spalten als Primärschlüssel.
  • Datastream sendet regelmäßig Heartbeat-Nachrichten an die Quelldatenbank, wenn eine Verbindung zu einer primären Instanz besteht. Dadurch werden Nachrichtenereignisse für die logische Decodierung (op:"m") direkt in die WAL-Datei eingefügt. Diese Nachrichten sind für Datastream erforderlich, um die Verfügbarkeit der Quelle zu gewährleisten und die Aktualität zu berechnen. Wenn Sie ein Lesereplikat als Quelle verwenden, müssen Sie Heartbeat-Nachrichten extern konfigurieren. Weitere Informationen finden Sie unter Replikation aus Lesereplikaten. Wir empfehlen, dies zu berücksichtigen, wenn andere Replikationskonfigurationen Daten aus derselben Quelldatenbank lesen.

Versionen

Datastream unterstützt PostgreSQL-Version 10 und höher.

Datastream unterstützt die folgenden Typen von PostgreSQL-Datenbanken:

  • Selbst gehostete PostgreSQL
  • Cloud SQL for PostgreSQL
  • AlloyDB for PostgreSQL
  • AlloyDB Omni
  • Amazon RDS for PostgreSQL
  • Amazon Aurora PostgreSQL

Kostenlose Stufe

Mit der kostenlosen Stufe von Datastream können Sie Daten aus AlloyDB for PostgreSQL in BigQuery streamen. Dabei erhalten Sie jeden Monat bis zu 100 GiB an Change Data Capture-Daten kostenlos. Weitere Informationen finden Sie unter Datastream – Preise.

Best Practices

In diesem Abschnitt werden empfohlene Best Practices für die Konfiguration Ihrer PostgreSQL-Quelle zur Verwendung mit Datastream beschrieben.

Mehrere Streams verwenden, um Blockierungen am Anfang der Warteschlange zu vermeiden

Bei PostgreSQL-Quellen verwendet Datastream einen einzelnen logischen Replikationsslot für einen gesamten Stream. Eine große Transaktion oder mehrere Aktualisierungen in einer Tabelle mit hohem Volumen können die Datenreplikation für alle anderen Tabellen im selben Stream verzögern.

Um Blockierungen am Anfang der Warteschlange zu vermeiden, erstellen Sie separate Streams für verschiedene Tabellensätze. Sie können beispielsweise einen Stream für Tabellen mit hohem Volumen und einen weiteren Stream für Tabellen mit geringem Volumen erstellen. Dadurch werden Tabellen mit hoher Änderungsrate isoliert und die Replikation für andere Tabellen nicht verzögert.

Empfehlung:Identifizieren Sie Tabellen mit besonders hohen Schreibraten (INSERT/UPDATE/DELETE) und platzieren Sie sie in einem eigenen Datastream-Stream mit einem separaten Replikationsslot.

Langlaufende Transaktionen vermeiden

Langlaufende Transaktionen können zu einer Ansammlung von WAL-Logs führen. Da WAL sequenziell ist, kann PostgreSQL alte WAL-Dateien, die für den Replikationsslot benötigt werden, erst entfernen, wenn die lange Transaktion abgeschlossen ist. Dadurch erhöht sich die WAL-Laufwerksnutzung.

Außerdem kann dies die logische Decodierung verlangsamen. Die Verlangsamung wird dadurch verursacht, dass bei großen Transaktionen Änderungen auf das Laufwerk ausgelagert werden. Dies erfordert dann eine langsame, E/A-intensive Neuzusammenstellung beim Commit, wodurch die Replikation aller nachfolgenden Transaktionen blockiert wird. Empfehlung:Konfigurieren Sie in der Quelldatenbank die Parameter statement_timeout und idle_in_transaction_session_timeout, um langlaufende Transaktionen zu vermeiden. Weitere Informationen finden Sie in der PostgreSQL-Dokumentation.

Tabellenfilterung beim Erstellen von Publikationen verwenden

Wenn Sie nur Änderungen aus einigen wenigen Tabellen replizieren, erstellen Sie eine PUBLICATION, die nur diese Tabellen enthält. Wenn eine Publikation auf bestimmte Tabellen beschränkt ist, speichert PostgreSQL Änderungen effizient nur für diese Tabellen im Replikationsslot. Dadurch wird die Größe des Replikationsslots reduziert und die Leistung der logischen Decodierung verbessert.

Replikationsslots proaktiv verwalten

Datastream verwendet einen logischen Replikationsslot in Ihrer primären PostgreSQL-Instanz. Dadurch wird sichergestellt, dass WAL-Dateien so lange aufbewahrt werden, bis Datastream bestätigt, dass sie verarbeitet wurden. Wenn ein Stream fehlschlägt, pausiert oder gelöscht wird, ohne dass der Replikationsslot gelöscht wird, behält PostgreSQL WAL-Dateien unbegrenzt bei. Dadurch kann das Laufwerk Ihres Datenbankservers voll werden und zu einem Produktionsausfall führen.

Empfehlung:Richten Sie effiziente Benachrichtigungen ein und beobachten Sie die WAL-Laufwerksnutzung auf Ihrem PostgreSQL-Quellserver.

Replikatsidentität richtig konfigurieren

Mit der Einstellung REPLICA IDENTITY wird PostgreSQL mitgeteilt, welche Daten für UPDATE- und DELETE-Ereignisse in die WAL-Datei geschrieben werden sollen. So kann Datastream erkennen, welche Zeilen geändert wurden.

Wenn Sie BigQuery als Ziel verwenden, legen Sie REPLICA IDENTITY nicht auf FULL fest. Datastream verwendet die protokollierten Spalten als logischen Schlüssel für MERGE-Vorgänge in BigQuery. Wenn REPLICA IDENTITY auf FULL gesetzt ist und eine Tabelle mehr als 16 Spalten hat, wird das Limit von 16 Spalten für Primärschlüssel in MERGE-Vorgängen in BigQuery überschritten und der Stream unterbrochen.

Empfehlungen (in der Reihenfolge der Präferenz):

  1. Beste Option:Verwenden Sie einen Primärschlüssel. Mit der Standardeinstellung REPLICA IDENTITY DEFAULT wird der vorhandene Primärschlüssel automatisch und effizient verwendet.
  2. Gute Option:Wenn kein Primärschlüssel vorhanden ist, erstellen Sie einen UNIQUE NOT NULL Index und legen REPLICA IDENTITY USING INDEX INDEX_NAME fest.
  3. Am wenigsten empfehlenswert:Verwenden Sie die Einstellung REPLICA IDENTITY FULL nur für Tabellen ohne eindeutige Kennung. Beachten Sie die Auswirkungen auf die Leistung und das Limit von 16 Spalten sowie die Einschränkung der unterstützten Datentypen für Primärschlüssel, wenn Sie Daten in BigQuery replizieren.

Replikation aus Lesereplikaten

Datastream unterstützt die Replikation aus PostgreSQL-Lesereplikatinstanzen für PostgreSQL-Version 16 und höher.

Wenn Sie Daten aus einem Lesereplikat replizieren möchten, müssen Sie die folgenden Einrichtungsschritte in der primären Instanz ausführen:

  1. Publikationen in der primären Instanz erstellen: Während Datastream eine Verbindung zum Lesereplikat herstellt, müssen die Publikationen, die die zu replizierenden Daten definieren, in der primären Instanz erstellt werden.
  2. WAL-Heartbeats konfigurieren: Datastream verwendet für den Checkpointing-Mechanismus regelmäßige WAL-Heartbeat-Nachrichten. Wenn eine Verbindung zu einer primären Instanz hergestellt wird, übernimmt Datastream die Generierung dieser Heartbeats. Bei einem Lesereplikat müssen diese Heartbeats jedoch extern generiert werden.

Eine Möglichkeit, regelmäßige Heartbeats einzurichten, besteht darin, mit der Erweiterung pg_cron einen Cron-Job in PostgreSQL zu erstellen:

SELECT cron.schedule_in_database(
    'datastream-heartbeat',             -- Job name
    '* * * * *',                        -- Every minute
   $$SELECT pg_logical_emit_message(true, 'datastream', 'cdc heartbeat')$$,
    'DATABASE_NAME',              -- Change this to your database name
    'USERNAME',                   -- Username to run as
    true                                -- Enabled
);

Ersetzen Sie Folgendes:

  • DATABASE_NAME: Der Name der Datenbank, für die Sie Heartbeats generieren möchten.
  • USERNAME: Der Name des Nutzers, als der der Job ausgeführt werden soll. Normalerweise postgres.

Bekannte Einschränkungen

Bekannte Einschränkungen bei Verwendung von Datastream mit einer PostgreSQL-Datenbank als Quelle:

  • Streams sind auf 10.000 Tabellen beschränkt.
  • PostgreSQL lehnt NULL-Bytes (0x00) in UTF-8-Stringspalten strikt ab. Datastream entfernt keine NULL-Bytes. Wenn ein Quellstring 0x00-NULL-Bytes enthält, schlägt der Einfügevorgang fehl und die Replikation wird beendet. Wir empfehlen, CHAR(0)-Zeichen in der Quelldatenbank zu bereinigen oder zu ersetzen, bevor Sie die Replikation durchführen.
  • Sie können PostgreSQL-Streams nicht so konfigurieren, dass sie an der letzten Position beginnen.
  • Für eine Tabelle mit mehr als 500 Millionen Zeilen ist kein Backfill möglich, es sei denn, die folgenden Bedingungen sind erfüllt:
    1. Die Tabelle hat einen eindeutigen B-Baum-Index.
    2. Der Index enthält keine Spalten der folgenden Typen: DOUBLE, FLOAT, MONEY, REAL, JSON, JSONB, BYTEA, TXID, XML, zusammengesetzte Datentypen oder geometrische Datentypen.
    3. Keine der Spalten des Index kann Nullwerte enthalten.
    4. Alle Spalten des Index sind in aufsteigender oder alle Spalten des Index in absteigender Reihenfolge.
    5. Alle Spalten des Index sind im Stream enthalten.
  • Tabellen ohne Primärschlüssel müssen eine REPLICA IDENTITY haben. Andernfalls werden nur INSERT-Ereignisse in das Ziel repliziert.
  • Für Tabellen mit Primärschlüsseln kann die REPLICA IDENTITY nicht auf FULL oder NOTHING gesetzt werden. Sie muss auf DEFAULT gesetzt sein.
  • Nicht alle Änderungen am Quellschema können automatisch erkannt werden. Dies kann zu Datenbeschädigungen führen. Die folgenden Schemaänderungen können zu Datenbeschädigungen oder Fehlern bei der nachgelagerten Verarbeitung der Ereignisse führen:
    • Spalten entfernen
    • Spalten in der Mitte einer Tabelle einfügen
    • Datentyp einer Spalte ändern
    • Spalten neu sortieren
    • Tabellen löschen (relevant, wenn dieselbe Tabelle anschließend mit neuen Daten neu erstellt wird)
  • Datastream unterstützt keine Spalten der geometric-Datentypen wie BOX, CIRCLE, LINE, LSEG, PATH, POINT und POLYGON. Solche Spalten werden als NULL repliziert.
  • Datastream unterstützt keine Spalten der range-Datentypen.
  • Datastream unterstützt keine Arrays nicht unterstützter Datentypen (z. B. räumliche Typen), Arrays von LTREE, Arrays benutzerdefinierter Datentypen (einschließlich ENUM) oder Arrays von DATE, TIMESTAMP oder TIMESTAMP WITH TIME ZONE (TIMESTAMPTZ). Datastream ignoriert solche Spalten bei der Replikation.
  • Für Streams, die vor dem 17. Februar 2026 erstellt wurden: Datastream unterstützt die Replikation von UPDATE-Ereignissen für Zeilen nicht, die TOAST-Werte in Spalten enthalten, die Teil der Replikatsidentität der Tabelle sind. Solche Ereignisse werden verworfen. Für Streams, die nach diesem Datum erstellt wurden, gilt diese Ausnahme nicht.
  • Datastream unterstützt keine Replikation von Zeilen, die JSON oder JSONB Werte mit mehr als 2.950 verschachtelten Objekten enthalten. Ereignisse mit solchen JSON oder JSONB Werten werden nicht in die Zieldatenbank repliziert.
  • Datastream unterstützt keine Replikation von Zeilen, die NaN-Werte in NUMERIC (precision, scale)-Spalten enthalten. Die Werte in solchen Spalten werden durch NULL-Werte ersetzt.
  • Datastream unterstützt keine Replikation von Spalten des Datentyps „hstore“. Die Werte in solchen Spalten werden durch NULL-Werte ersetzt.
  • Datastream unterstützt keine Replikation von Nicht-ASCII-Einträgen aus einer mit SQL_ASCII codierten Quelldatenbank. Solche Einträge werden verworfen.
  • Datastream unterstützt keine Replikation von Tabellen, für die RLS-Richtlinien (Row-Level Security) definiert sind. Informationen zum Umgehen dieser Einschränkung finden Sie unter Verhalten und Einschränkungen von PostgreSQL-Quellen.
  • Für das Streamen von Spalten mit Datentypen variabler Länge, die TOAST (The Oversized-Attribute Storage Technique) verwenden: Wenn ein unveränderter TOAST-Wert während eines UPDATE Vorgangs aus dem WAL-Log entfernt wird, führt Datastream eine aktive Suche in der Quelldatenbank durch, um den fehlenden Wert wiederherzustellen. Daher werden Zwischenänderungen in Szenarien mit schnellen, aufeinanderfolgenden Aktualisierungen oder einer schnellen Löschung nach dem Einfügen möglicherweise nicht erfasst. DELETE-Vorgänge lösen diese aktive Suche nicht aus. Diese Einschränkung für Spalten variabler Länge, die TOAST verwenden, ist besonders relevant, wenn der Schreibmodus „Nur anhängen“ verwendet wird, bei dem alle Zwischenänderungen erfasst werden müssen.
  • Datastream erfasst keine Änderungen an generierten Spalten.
  • Datastream funktioniert möglicherweise nicht mehr oder erfasst keine neuen Ereignisse, wenn ein Upgrade der PostgreSQL-Hauptversion für die Datenbank durchgeführt wird. Wir empfehlen, die Replikationsslots vor dem Upgrade zu löschen, dann die Datenbank zu aktualisieren und anschließend die Replikationsslots neu zu erstellen. Wenn die Streams fehlschlagen, stellen Sie den Stream wieder her, indem Sie den neuen Namen des Replikationsslots angeben. Führen Sie einen Backfill durch, wenn Datenkonsistenz erforderlich ist.
  • Datastream unterstützt keine Replikation von PostgreSQL-Systemtabellen, wenn Sie den automatisierten Stream-Einrichtungsablauf verwenden. Wenn Sie den Stream bearbeiten, den Sie mit dem automatisierten Ablauf erstellt haben, und Systemtabellen hinzufügen, ignoriert Datastream diese Tabellen und repliziert keine Daten oder Änderungen daraus.

Nächste Schritte