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 eine REPLICA IDENTITY für eine Tabelle 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 Datastream können Sie über die kostenlose Stufe 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 außergewöhnlich 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 die Festplatte 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 nur für diese Tabellen effizient 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 die Festplatte Ihres Datenbankservers voll werden und zu einem Produktionsausfall führen.

Empfehlung:Richten Sie effiziente Benachrichtigungen ein und überwachen 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 geschrieben werden sollen, damit Datastream erkennen kann, 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 BigQuery-MERGE-Vorgänge. 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, das Limit von 16 Spalten und 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 regelmäßige WAL-Heartbeat-Nachrichten für den Checkpointing-Mechanismus. 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.
  • 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 darf die REPLICA IDENTITY nicht auf FULL oder NOTHING gesetzt sein. 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.
  • Datastream unterstützt keine Spalten der range-Datentypen.
  • Datastream unterstützt keine Arrays nicht unterstützter Datentypen, Arrays benutzerdefinierter Datentypen (einschließlich ENUM) oder Arrays der Datentypen DATE, TIMESTAMP oder TIMESTAMP WITH TIME ZONE. Solche Spalten werden ignoriert.
  • Für Streams, die vor dem 17. Februar 2026 erstellt wurden: Datastream unterstützt keine Replikation von UPDATE-Ereignissen für Zeilen, 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, die solche JSON oder JSONB Werte enthalten, 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 SQL_ASCII-codierten Quelldatenbank. Solche Einträge werden verworfen.
  • Datastream unterstützt keine Replikation von Tabellen mit definierten RLS-Richtlinien (Row-Level Security). Informationen zum Umgehen dieser Einschränkung finden Sie unter Verhalten und Einschränkungen der PostgreSQL-Quelle.
  • Beim Streamen von Spalten mit Datentypen variabler Länge, die TOAST (The Oversized-Attribute Storage Technique) verwenden, muss Datastream die Quelldatenbank abfragen, um fehlende Werte zu einem bestimmten Zeitpunkt abzurufen (in einem aktiven Suchvorgang namens Ergänzung), wenn ein unveränderter TOAST-Wert während eines UPDATE-Vorgangs aus dem WAL-Log entfernt wird. Da Datastream diese Spalten durch Abfragen der Datenbank streamt, 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 keine Ergänzung aus. Diese Einschränkung 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 dann die Replikationsslots neu zu erstellen. Wenn die Streams fehlschlagen, stellen Sie den Stream wieder her, indem Sie den neuen Namen des Replikationsslots angeben, und 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