Replication Slot ist ein PostgreSQL-Mechanismus für Replikation und Change Data Capture: Er merkt sich dauerhaft die Position im Write-Ahead-Log, bis zu der ein Konsument die Daten bereits verarbeitet hat. Damit geht keine Änderung verloren, selbst wenn der Empfänger zwischenzeitlich ausfällt.
So funktioniert logisches Decoding
Für logisches Decoding muss PostgreSQL mit wal_level=logical laufen und max_replication_slots gesetzt sein. Ein Slot wird über SQL oder den Replikations-Protokoll angelegt. Der WALSender liest die WAL-Einträge ab der Position des Slots und übergibt sie dem Decoder, der daraus Change-Events erzeugt — diese fließen dann an Werkzeuge wie Debezium.
confirmed_flush_lsn und restart_lsn
Ein Slot führt zwei Positionen: confirmed_flush_lsn markiert, bis wohin der Konsument die Daten bereits bestätigt hat — logisches Decoding liefert nichts davor. restart_lsn markiert, ab wann PostgreSQL das WAL für das Decoding noch benötigt, weil ältere Transaktionen Einfluss auf die Berechnung haben können. Der Slot ist crash-sicher und persistiert unabhängig von der Verbindung.
Achtung: WAL-Wachstum
Wird ein Slot nicht konsumiert, hält PostgreSQL das gesamte WAL seit restart_lsn zurück — das Verzeichnis pg_wal wächst dann unbegrenzt und kann die Platte füllen. Ungenutzte Slots sollten daher überwacht und entfernt werden. In Kombination mit Snapshot-then-Stream und log-basierter CDC bildet der Slot die verlässliche Fortsetzungsposition.
Verwandte Grundlagen: Message Queue, Event Sourcing, PostgreSQL-Befehle.