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 das Feature Logische Decodierung zurück. Bei der logischen Decodierung werden alle Änderungen, die in der Datenbank vorgenommen wurden, verfügbar gemacht. Diese Änderungen können dann in einem nutzerfreundlichen Format mithilfe eines Ausgabeprogramms genutzt und verarbeitet werden. Datastream verwendet das pgoutput-Plug-in, das das standardmäßige PostgreSQL-Plug-in für die logische Decodierung 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 DML-Änderungen (Data Manipulation Language, 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. Daher werden Ereignisse für logische Decodierungsnachrichten (op:"m") direkt in die WAL-Datei eingefügt. Diese Meldungen sind für Datastream erforderlich, um die Verfügbarkeit der Quelle zu gewährleisten und die Aktualität zu berechnen. Das sollten Sie berücksichtigen, wenn andere Replikationseinrichtungen 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

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 Head-of-Line-Blockierung zu verhindern

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 Head-of-Line-Blocking zu verhindern, erstellen Sie separate Streams für verschiedene Tabellengruppen. Sie können beispielsweise einen Stream für Tabellen mit hohem Volumen und einen weiteren Stream für Tabellen mit niedrigem Volumen erstellen. So werden Tabellen mit hoher Churn-Rate isoliert und die Replikation für andere Tabellen wird nicht verzögert.

Empfehlung:Identifizieren Sie Tabellen mit besonders hohen Schreibvorgängen (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 einem Anstieg des Write-Ahead-Logs (WAL) führen. Da WAL sequenziell ist, kann PostgreSQL den WAL erst leeren, wenn die lange Transaktion abgeschlossen ist, auch wenn andere Transaktionen verarbeitet werden. Dies kann die Größe des Replikations-Slots erhöhen und die logische Dekodierung verlangsamen, da Änderungen aus lang andauernden Transaktionen, die sich mit der aktuellen Transaktion überschneiden, wiederholt dekodiert werden müssen.

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, werden Änderungen in PostgreSQL effizient nur für diese Tabellen im Replikations-Slot gespeichert. Dadurch wird die Größe des Replikations-Slots reduziert und die Leistung der logischen Dekodierung verbessert.

Replikationsslots proaktiv verwalten

Datastream verwendet einen logischen Replikationsslot auf Ihrer primären PostgreSQL-Instanz. Dadurch wird sichergestellt, dass WAL-Dateien beibehalten 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 weiterhin auf unbestimmte Zeit bei. Dadurch kann die Festplatte Ihres Datenbankservers voll werden und es kann zu einem Produktionsausfall kommen.

Empfehlung:Richten Sie effiziente Benachrichtigungen ein und überwachen Sie die WAL-Festplattennutzung 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. So kann Datastream erkennen, 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 festgelegt 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. Optimal:Verwenden Sie einen Primärschlüssel. Bei der Standardeinstellung von 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 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.

Bekannte Einschränkungen

Bekannte Einschränkungen bei der 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 kann kein Backfill durchgeführt werden, 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 absteigender Reihenfolge sortiert.
    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 zum Ziel repliziert.
  • Bei Tabellen mit Primärschlüsseln kann REPLICA IDENTITY nicht auf FULL oder NOTHING festgelegt werden. Es muss auf DEFAULT gesetzt sein.
  • Datastream kann nicht von einer Lesereplikatinstanz replizieren, da PostgreSQL die logische Decodierung in Lesereplikaten nicht unterstützt.
  • 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 anordnen
    • Tabellen löschen (relevant, wenn dieselbe Tabelle anschließend mit neuen Daten neu erstellt wird)
  • Datastream unterstützt keine Spalten mit den Datentypen geometric.
  • Datastream unterstützt keine Spalten mit den Datentypen range.
  • Datastream unterstützt keine Arrays von nicht unterstützten Datentypen, Arrays von nutzerdefinierten Datentypen (einschließlich ENUM) oder Arrays von DATE-, TIMESTAMP- oder TIMESTAMP WITH TIME ZONE-Datentypen. Solche Spalten werden ignoriert.
  • Datastream unterstützt die Replikation von UPDATE-Ereignissen für Zeilen, die TOAST-Werte in Spalten enthalten, die Teil der Replikatidentität der Tabelle sind, nicht. Solche Ereignisse werden verworfen.
  • 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 Datensätzen, die nicht in ASCII codiert sind, aus einer SQL_ASCII-codierten Quelldatenbank. Solche Datensätze werden verworfen.
  • Datastream unterstützt keine Replikation von Tabellen mit definierten Richtlinien für die Sicherheit auf Zeilenebene (Row-Level Security, RLS). Informationen dazu, wie Sie diese Einschränkung umgehen können, finden Sie unter Verhalten und Einschränkungen von PostgreSQL-Quellen.
  • Mit Datastream werden keine Änderungen an generierten Spalten erfasst.
  • 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 Replikations-Slots vor dem Upgrade zu löschen, dann die Datenbank zu aktualisieren und die Replikations-Slots anschließend neu zu erstellen. Wenn die Streams fehlschlagen, stellen Sie sie wieder her, indem Sie den neuen Namen des Replikationsslots angeben. Führen Sie außerdem einen Backfill durch, wenn Datenkonsistenz erforderlich ist.

Nächste Schritte