TOAST wurde in PostgreSQL eingeführt, um Zeilendaten zu verarbeiten, die die Seitengröße von 8 KB überschreiten, indem große Spalten in separaten physischen Speicher komprimiert werden. Wenn logische Replikation Änderungen über das WAL streamt, bestimmt die Einstellung REPLICA IDENTITY, welche alten Tupelwerte eingeschlossen werden. Die Standard-REPLICA IDENTITY DEFAULT sendet nur den Primärschlüssel, während REPLICA IDENTITY FULL das vollständige alte Zeilenbild sendet.
Wenn eine Tabelle JSONB- oder TEXT-Spalten enthält, die ~2 KB überschreiten und in TOAST komprimiert sind, könnten UPDATE-Operationen, die nur nicht-TOAST-Spalten ändern, die externen TOAST-Werte für den WAL-Datensatz möglicherweise nicht abrufen. Der Prozess der logischen Dekodierung überspringt unveränderte TOAST-Zeiger, um I/O zu reduzieren, wodurch der Subscriber NULL oder fehlende Werte für diese großen Felder während der Konfliktlösung erhält.
Ein Wechsel zu REPLICA IDENTITY FULL zwingt PostgreSQL, das vollständige alte Tupel im WAL-Datensatz einzuschließen, indem während des Commits ausdrücklich alle TOAST-Werte aus dem externen Speicher abgerufen werden. Während dies die Datenvollständigkeit für UPSERT-Operationen garantiert, erhöht es das WAL-Volumen erheblich – oft um 300-500 % für breite JSONB-Tabellen – da jedes UPDATE das vollständige Pre-Image der Zeile protokollieren muss.
Eine Finanzhandelsplattform musste Auftragsbuch-Schnappschüsse von einem primären PostgreSQL 15-Cluster in ein Data Warehouse zur regulatorischen Berichterstattung replizieren. Die Tabelle market_data speicherte Instrumenten-IDs und große JSONB-Payloads (10-50 KB), die Informationen zur Markttiefe enthielten. Die Replikation verwendete pglogical mit REPLICA IDENTITY DEFAULT (nur Primärschlüssel). Der ETL-Prozess auf der Data-Warehouse-Seite versuchte, UPSERT-Operationen durchzuführen, um eine sich langsam ändernde Dimensionstabelle zu pflegen, was die alten JSONB-Werte erforderte, um Delta-Änderungen für das Audit-Protokoll zu berechnen.
Während Phasen mit hohem Handelsvolumen, als das Auftragsbuch häufig aktualisiert wurde, aber die JSONB-Payload unverändert blieb, sendete der logische Replikationsstream UPDATE-Datensätze, die nur den Primärschlüssel und die neuen Tupeldaten enthielten. Die TOAST-alten Werte von JSONB wurden nicht im Änderungsset enthalten, da die UPDATE-Anweisung nur die updated_at-Zeitstempelspalte berührte. Der ETL-Prozess konnte auf den Pre-Update-JSONB-Zustand nicht zugreifen, was eine präzise Berechnung der Preisbewegungsdeltas für den Audit-Trail unmöglich machte und die Anforderungen der MiFID II-Konformität verletzte.
Lösung 1: Wechsel zu REPLICA IDENTITY FULL Dieses Vorgehen würde den Publisher zwingen, das vollständige alte Zeilenbild für jedes UPDATE in das WAL zu schreiben, einschließlich des vollständigen JSONB-Inhalts aus dem TOAST-Speicher. Die Vorteile umfassten die garantierte Datenvollständigkeit und eine einfache Implementierung, die keine Änderungen des Schemas erforderte. Die Nachteile waren erheblich: Die WAL-Generierung würde um etwa 400 % ansteigen, angesichts der 50 KB-Payloads, was das Risiko einer Erschöpfung des Speicherplatzes auf dem Primär-Server und eine erhöhte Netzwerkverzögerung zum Data Warehouse mit sich brachte. Für eine Tabelle, die 10.000 Updates pro Sekunde verarbeitet, wurde dies als zu riskant für die Produktionsstabilität angesehen.
Lösung 2: Anwendungsbasiertes Journaling mit einer separaten Historientabelle
Das Team erwog, einen Trigger auf dem Primär-Server zu erstellen, der die alten JSONB-Werte vor dem Update in eine separate market_data_history-Tabelle kopierte. Die Vorteile waren, dass die logische Replikation diese Historientabelle separat replizieren konnte, wodurch das Problem des TOAST-Auslassens in der Haupttabelle vermieden wurde, während der WAL-Fußabdruck der Haupttabelle klein blieb. Die Nachteile umfassten zusätzliche Schreiblast auf dem Primär-Server (die die Transaktionslatenz erhöht), zusätzliche Speicheranforderungen, die mit einer Rate von 2x wachsen, und Komplexität in der ETL-Logik, um Historienaufzeichnungen mit Änderungen der Haupttabelle unter Verwendung von Transaktions-IDs und Zeitstempeln zu korrelieren.
Lösung 3: Verwendung von REPLICA IDENTITY mit einem abdeckenden Index, der einen Hash des JSONB enthält
Diese Strategie beinhaltete die Erstellung eines funktionalen Index auf md5(jsonb_column::text) und die Einbeziehung dieses Hash in einen zusammengesetzten REPLICA IDENTITY-Index. Die Vorteile waren, dass Änderungen am JSONB-Inhalt über die Änderung des Hashs im WAL erkennbar wären, ohne die vollständige Payload zu senden. Die Nachteile umfassten die Unfähigkeit, den tatsächlichen alten Wert abzurufen (nur seinen Hash), was unzureichend für die regulatorische Anforderung war, den exakten Pre-Update-Zustand zu zeigen, und die Indexpflegekosten bei stark wechselnden Tabellen.
Das Team wählte Lösung 2 (Anwendungsbasiertes Journaling), jedoch mit einer Modifikation. Sie verwendeten die partielle Update-Optimierung von PostgreSQL für JSONB, die in Version 14+ verfügbar ist, und implementierten einen BEFORE UPDATE-Trigger, der nur die geänderten Pfade (Diff) speicherte, anstatt die vollständige alte Zeile. Dies reduzierte das Wachstum der Historientabelle, während sichergestellt wurde, dass alle erforderlichen Pre-Image-Daten verfügbar waren. Sie behielten REPLICA IDENTITY DEFAULT für die Haupttabelle bei, um WAL-Bloat zu vermeiden, und leiteten die ETL-Prozesse an, gegen die Historientabelle für die Audit-Rekonstruktion zu joinen.
Die Größe des Replikationsstreams blieb stabil, was Druck auf den Primärspeicher verhinderte. Der ETL-Prozess rekonstruierte erfolgreich vollständige Audit-Trails, indem er den aktuellen Zeilenstatus mit den gespeicherten Diffs aus der Historientabelle zusammenführte. Die regulatorische Compliance wurde erreicht, mit nur einer 15%igen Erhöhung des Primärspeichers (im Vergleich zu 400% für REPLICA IDENTITY FULL) und minimalen Auswirkungen auf den Transaktionsdurchsatz.
Warum überspringt die logische Dekodierung von PostgreSQL TOAST-Werte, selbst wenn die Spalte modifiziert wird?
Viele Kandidaten nehmen an, dass jedes UPDATE automatisch alle TOAST-Werte für den WAL abruft. Doch PostgreSQL führt "Tuple unTOASTing" nur durch, wenn der Executor tatsächlich das Datum zum Modifizieren liest. Wenn ein UPDATE eine andere Spalte ändert (z.B. SET updated_at = NOW()), ohne die JSONB-Spalte in seiner Ziel-Liste oder WHERE-Klausel zu referenzieren, bleibt der TOAST-Zeiger unverändert und der externe Speicher wird nicht abgerufen. Der WAL-Datensatz enthält daher nur das auf der Festplatte befindliche Tupel mit seinem Zeiger, nicht die tatsächlichen Daten. Da die logische Dekodierung Tupel aus dem WAL rekonstruiert, ohne auf Heap- oder TOAST-Tabellen für alte Versionen zuzugreifen, erscheint der ausgelassene Wert im Änderungsstream als NULL.
Wie interagiert REPLICA IDENTITY FULL mit HOT (Heap-Only Tuple)-Updates?
Kandidaten übersehen oft, dass REPLICA IDENTITY FULL HOT-Updates für eine Tabelle deaktiviert. HOT-Updates ermöglichen es PostgreSQL, Zeilenversionen innerhalb derselben Datenpage zu verketten, ohne jeden Indexeintrag zu aktualisieren, sofern sich keine indizierte Spalte ändert. Wenn REPLICA IDENTITY FULL aktiv ist, muss jedes UPDATE das gesamte alte Zeilenbild für die Replikation protokollieren, was das System zwingt, die Zeile eindeutig durch ihren vollständigen Inhalt zu identifizieren. Dies bricht die HOT-Optimierung, weil die logische Replikation vollständige Tupelvergleichsdaten benötigt, wodurch Indexaktualisierungen für jede Zeilenversion notwendig werden, selbst wenn nicht-indizierte Spalten geändert werden. Folglich erleben Tabellen mit dieser Einstellung ein höheres Indexwuchern und erhöhte I/O, ein kritischer Kompromiss für stark wechselnde Tabellen.
Was ist der Unterschied zwischen TOAST-Kompression und PostgreSQLs WAL-Kompression, und wie interagieren sie während der logischen Replikation?
Diese Frage trennt tiefes Systemwissen von oberflächlichem Verständnis. TOAST-Kompression reduziert die Zeilengröße unter Verwendung von LZ4 oder PGLZ, bevor große Spalten in externen Tabellen gespeichert werden. WAL-Kompression (aktiviert durch wal_compression=lz4) komprimiert vollständige Seitenbilder, die in das WAL für Effizienz der Crashwiederherstellung geschrieben werden. Wenn jedoch REPLICA IDENTITY FULL verwendet wird, werden die alten Tupel-Daten, die an die logische Dekodierung gesendet werden, vor der Komprimierung des WAL-Datensatzes für die Speicherung extrahiert. Daher erhält der logische Dekodierer unkomprimierte TOAST-Daten (wenn abgerufen), während die physische WAL-Datei sie komprimiert speichern könnte, wenn sie Teil eines vollständigen Seitenbilds ist, was sich unterschiedlich auf die Netzwerkbandbreite gegenüber der Festplatten-I/O auswirkt.