Daten aus PostgreSQL-Datenbanken streamen

Mit Datastream können Sie Verlaufsdaten und laufende Änderungen aus einer PostgreSQL-Datenbank in Ihr Ziel replizieren, um Echtzeitanalysen und Datenbanksynchronisierung durchzuführen.

Wenn Sie sich auf die PostgreSQL-Replikation in Datastream vorbereiten möchten, lesen Sie die Informationen zum Replikationsverhalten, zu den unterstützten Versionen und Datenbanktypen, zu den Best Practices, zu den Anforderungen für Lesereplikate und zu den bekannten Einschränkungen.

Verhalten

Die PostgreSQL-Quelldatenbank verwendet die Funktion Logische Decodierung. Bei der logischen Decodierung werden alle Änderungen an der Datenbank offengelegt. Diese Änderungen können dann mit einem Ausgabe-Plug-in in einem nutzerfreundlichen Format genutzt und verarbeitet werden. Datastream verwendet das pgoutput-Plug-in, das das standardmäßige logische Decodierungs-Plug-in für PostgreSQL 10 und höher ist.

  • Sie können alle Schemas oder bestimmte Schemas aus einer bestimmten PostgreSQL-Quelle sowie alle Tabellen aus dem Schema oder bestimmte Tabellen auswählen.
  • Alle Verlaufsdaten werden repliziert.
  • Alle Änderungen der Datenbearbeitungssprache (Data Manipulation Language, DML), z. B. 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. Daher werden Ereignisse für logische Decodierungsnachrichten (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 Replikationseinrichtungen aus derselben Quelldatenbank lesen.

Versionen

Datastream unterstützt PostgreSQL ab Version 10.

Datastream unterstützt die folgenden PostgreSQL-Datenbanktypen:

  • 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 Daten von AlloyDB for PostgreSQL zu BigQuery streamen. In der kostenlosen Stufe sind bis zu 100 GiB Change Data Capture-Daten pro Monat kostenlos. Weitere Informationen finden Sie unter Datastream-Preise.

Best Practices

In diesem Abschnitt werden empfohlene Best Practices für die Konfiguration Ihrer PostgreSQL-Quelle für die 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.

Erstellen Sie separate Streams für verschiedene Tabellensätze, um Head-of-Line-Blocking zu verhindern. Sie können beispielsweise einen Stream für Tabellen mit hohem Volumen und einen anderen Stream für Tabellen mit geringem Volumen erstellen. Dadurch werden Tabellen mit hoher Abwanderung isoliert und die Replikation für andere Tabellen wird 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 Replikations-Slot.

Lang andauernde Transaktionen vermeiden

Lang andauernde Transaktionen können zu einer Anhäufung von WAL-Logs führen. Da WAL sequenziell ist, kann PostgreSQL alte WAL-Dateien, die vom Replikations-Slot 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 durch große Transaktionen verursacht, die Änderungen auf das Laufwerk schreiben. Dies erfordert beim Commit eine langsame, E/A-intensive Neuzusammenstellung, 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 lang andauernde Transaktionen zu vermeiden. Weitere Informationen finden Sie in der PostgreSQL-Dokumentation.

Tabellenfilter beim Erstellen von Publikationen verwenden

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

Replikationsslots proaktiv verwalten

Datastream verwendet einen logischen Replikationsslot auf Ihrer primären PostgreSQL-Instanz. Dadurch wird sichergestellt, dass WAL-Dateien 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 die WAL-Dateien auf unbestimmte Zeit bei. Dies kann dazu führen, dass das Laufwerk des Datenbankservers voll wird und es zu einem Produktionsausfall kommt.

Empfehlung: Richten Sie effiziente Benachrichtigungen ein und überwachen Sie die WAL-Speichernutzung auf Ihrem PostgreSQL-Quellserver.

Replikatidentität richtig konfigurieren

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

Wenn Sie BigQuery als Ziel verwenden, sollten Sie REPLICA IDENTITY nicht auf FULL festlegen. 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 BigQuery-Limit von 16 Spalten für Primärschlüssel in MERGE-Vorgängen überschritten und der Stream wird unterbrochen.

Empfehlungen (in der Reihenfolge der Präferenz):

  1. Am besten: Verwenden Sie einen Primärschlüssel. Bei der Standardeinstellung REPLICA IDENTITY DEFAULT wird der vorhandene Primärschlüssel automatisch und effizient verwendet.
  2. Gut: Wenn kein Primärschlüssel vorhanden ist, erstellen Sie einen UNIQUE NOT NULL-Index und legen Sie REPLICA IDENTITY USING INDEX INDEX_NAME fest.
  3. Am wenigsten empfohlen: 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 nach BigQuery replizieren.

Replikation aus Lesereplikaten

Datastream unterstützt die Replikation von PostgreSQL-Lesereplikatinstanzen für PostgreSQL-Versionen ab 16.

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

  1. Publikationen auf der primären Instanz erstellen: Während Datastream eine Verbindung zum Lesereplikat herstellt, müssen die Publikationen, die die zu replizierenden Daten definieren, auf der primären Instanz erstellt werden.
  2. WAL-Heartbeats konfigurieren: Datastream verwendet für seinen Prüfpunktmechanismus 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, in PostgreSQL mit der Erweiterung pg_cron einen Cron-Task 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 die Aufgabe ausgeführt werden soll. In der Regel postgres.

Bekannte Einschränkungen

Für die Verwendung von Datastream mit einer PostgreSQL-Datenbank als Quelle gelten unter anderem folgende bekannte Einschränkungen:

  • Streams sind auf 10.000 Tabellen beschränkt.
  • PostgreSQL lehnt NULL-Byte (0x00) in UTF-8-Stringspalten strikt ab. Datastream entfernt keine NULL-Bytes. Wenn ein Quellstring 0x00-Null-Byte enthält, schlägt der Einfüge-Batch fehl und die Replikation wird beendet. Wir empfehlen, CHAR(0)-Zeichen in der Quelldatenbank vor der Replikation zu bereinigen oder zu ersetzen.
  • Sie können PostgreSQL-Streams nicht so konfigurieren, dass sie an der letzten Position beginnen.
  • Eine Tabelle mit mehr als 500 Millionen Zeilen kann nur dann mit Backfill-Daten gefüllt werden, wenn die folgenden Bedingungen erfüllt sind:
    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 darf Nullwerte enthalten.
    4. Alle Spalten des Index sind in aufsteigender Reihenfolge oder alle Spalten des Index sind 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.
  • Bei Tabellen mit Primärschlüsseln kann REPLICA IDENTITY nicht auf FULL oder NOTHING festgelegt werden. Sie muss auf DEFAULT festgelegt 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 hinzufügen
    • Datentyp einer Spalte ändern.
    • Spalten neu sortieren
    • Tabellen löschen (relevant, wenn dieselbe Tabelle dann mit neuen Daten neu erstellt wird)
  • Datastream unterstützt keine Spalten der geometric-Datentypen, z. B. BOX, CIRCLE, LINE, LSEG, PATH, POINT und POLYGON. Solche Spalten werden als NULL repliziert.
  • Datastream unterstützt keine Spalten mit den Datentypen range.
  • Datastream unterstützt keine Arrays von nicht unterstützten Datentypen (z. B. räumliche Typen), Arrays von LTREE, Arrays von benutzerdefinierten Datentypen (einschließlich ENUM) oder Arrays von DATE, TIMESTAMP oder TIMESTAMP WITH TIME ZONE (TIMESTAMPTZ). Datastream ignoriert solche Spalten während der Replikation.
  • Für Streams, die vor dem 17. Februar 2026 erstellt wurden: Datastream unterstützt nicht die Replikation von UPDATE-Ereignissen für Zeilen, die TOAST-Werte in Spalten enthalten, die Teil der Replikatidentität der Tabelle sind. Solche Ereignisse werden verworfen. Streams, die nach diesem Datum erstellt wurden, sind von dieser Ausnahme nicht betroffen.
  • Datastream unterstützt nicht die 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 nicht die 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 die Replikation von Spalten des Datentyps hstore nicht. Die Werte in solchen Spalten werden durch NULL-Werte ersetzt.
  • Datastream unterstützt nicht die 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 Richtlinien für die Sicherheit auf Zeilenebene (Row-Level Security, RLS). Informationen zum Umgehen dieser Einschränkung finden Sie unter Verhalten und Einschränkungen von PostgreSQL-Quellen.
  • Für Streaming-Spalten mit Datentypen variabler Länge, die die Oversized-Attribute Storage Technique (TOAST) verwenden: Wenn ein unveränderter TOAST-Wert während eines UPDATE-Vorgangs aus dem WAL-Log gelöscht 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 einem schnellen Löschen nach einem Einfügen möglicherweise nicht erfasst. Beachten Sie, dass DELETE-Vorgänge diesen aktiven Suchvorgang nicht auslösen. Diese Einschränkung für Spalten mit variabler Länge, die TOAST verwenden, ist besonders relevant, wenn der Nur-Anhängen-Schreibmodus verwendet wird, bei dem alle Zwischenänderungen erfasst werden sollen.
  • 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 Replikationsslotnamen angeben, und führen Sie einen Backfill durch, wenn Datenkonsistenz erforderlich ist.
  • Datastream unterstützt die Replikation von PostgreSQL-Systemtabellen nicht, wenn der automatisierte Stream-Einrichtungsablauf verwendet wird. Wenn Sie den Stream bearbeiten, den Sie mit dem automatisierten Ablauf erstellt haben, und Systemtabellen hinzufügen, ignoriert Datastream diese Tabellen stillschweigend und repliziert keine Daten oder Änderungen daraus.

Nächste Schritte