Read-Replikas und Replikationsverzögerung: Wie veraltete Lesezugriffe aussehen und wie man sie begrenzt

Worum es geht

Bei der Streaming-Replikation in PostgreSQL sendet der Primärserver Write-Ahead-Log-Einträge an Standbys, die sie wiedergeben; ein Hot Standby bedient auch lesende Abfragen. Replikation ist standardmässig asynchron: Ein Commit kehrt zurück, bevor irgendein Standby die Daten hat. Die zitierte Dokumentation beschreibt synchronous_commit-Stufen, die einen Commit warten lassen, bis ein Standby die Transaktion geschrieben, geflusht oder, bei remote_apply, wiedergegeben hat, sodass sie für Abfragen dort sichtbar ist, was laut Dokumentation in einfachen Fällen Lastverteilung mit kausaler Konsistenz erlaubt; die beteiligten Standbys werden in synchronous_standby_names benannt.

Wiedergabe und Abfragen konkurrieren miteinander. Die zitierte Dokumentation zum Hot Standby erklärt, dass die WAL-Anwendung mit laufenden Abfragen in Konflikt geraten kann (etwa wenn eine Zeile, die eine Abfrage benötigt, auf dem Primärserver bereits bereinigt wurde); nach max_standby_streaming_delay wird die konfliktverursachende Abfrage abgebrochen, und hot_standby_feedback verhindert, dass VACUUM auf dem Primärserver Zeilen entfernt, die ein Standby noch benötigt, auf Kosten von Bloat auf dem Primärserver. Überwachung erfolgt über pg_stat_replication auf dem Primärserver und die zitierten Funktionen zur Wiedergabeposition, etwa pg_last_wal_replay_lsn(), auf dem Standby.

Warum es wichtig ist

Der typische Fehler: Eine Nutzerin sendet ein Formular ab (Schreibzugriff auf den Primärserver), die nächste Seite listet Elemente auf (Lesezugriff auf die Replika), und das neue Element fehlt; ein erneuter Versuch zeigt es. Hintergrundjobs, die von einer Replika lesen, handeln auf Basis veralteten Zustands. Das sind keine seltenen Randfälle, sondern das normale Verhalten unter Verzögerung.

So wird es angewendet

• Lesezugriffe klassifizieren: Lesezugriffe nach einem Schreibzugriff im selben Nutzerablauf gehen an den Primärserver oder bleiben nach einem Schreibzugriff dieser Sitzung für kurze Zeit an ihn gebunden; Dashboards und Suche können Replikas frei nutzen.
• Für eine strikte Read-your-writes-Prüfung die Commit-Position des Primärservers festhalten und den Lesezugriff auf der Replika erst zulassen, wenn deren Wiedergabeposition sie erreicht hat.
• Analytischen Replikas eine grosse Standby-Verzögerung geben, damit lange Abfragen nicht abgebrochen werden; auf Replikas, die latenzempfindliche Lesezugriffe bedienen, die Verzögerung kurz halten.
• Bei Verzögerung in Byte und Sekunden sowie bei der Anzahl abgebrochener Abfragen auf jedem Standby alarmieren.
• Synchrone Modi nur für jene Standbys und Workloads verwenden, bei denen die zusätzliche Commit-Latenz und das Risiko blockierter Commits bei einem ausgefallenen Standby akzeptiert werden.

Stolpersteine

Ein Proxy, der Anweisungen nach Typ weiterleitet (jedes SELECT an eine Replika), kann die eigenen Lesezugriffe einer Transaktion vom Primärserver weglenken, sofern er die Transaktion nicht nachverfolgt. Eine beim Failover beförderte Replika kann hinter dem alten Primärserver zurückliegen, sodass mit asynchroner Replikation jüngste Commits verloren gehen können. Die Verzögerung wächst unter starker Schreiblast genau dann, wenn die Lesezugriffe am stärksten sind.