Postgres-Replikation überwachen: Warum "HA mit Replica" nicht gleich Hochverfügbarkeit bedeutet

Eine PostgreSQL-Replikation schafft keine Hochverfügbarkeit, solange ihre Komponenten und Metriken unsichtbar bleiben. Viele Teams setzen Replikate ein, um Ausfälle abzufedern – doch wenn eine Replikation abbricht, bleibt dies oft monatelang unbemerkt. Erst beim nächsten Ausfall des Primärsystems stellt sich heraus, dass die vermeintliche Hochverfügbarkeitslösung längst zu einem Single-Point-of-Failure verkommen ist.

Wenn Sie also glauben, eine Replikation sei gleichbedeutend mit Hochverfügbarkeit, irren Sie sich. Dieser Artikel zeigt, wie Sie mit einem spezialisierten Dashboard und gezielten Alerts Replikationsprobleme erkennen, bevor sie zu kritischen Ausfällen führen.

Wie PostgreSQL-Replikation technisch funktioniert

PostgreSQL nutzt das Write-Ahead-Logging (WAL), um Transaktionsdaten zwischen Primär- und Replikatserver zu synchronisieren. Der Prozess basiert auf vier zentralen Mechanismen:

• WAL-Sender auf dem Primärserver: Dieser Prozess liest kontinuierlich die WAL-Dateien und streamt die Daten an verbundene Replikate.
• WAL-Empfänger auf dem Replikat: Er empfängt die Daten, schreibt sie in die lokale WAL-Verzeichnisstruktur und überträgt sie anschließend in den Arbeitsspeicher.
• Startup-Prozess auf dem Replikat: Dieser wendet die empfangenen WAL-Einträge auf die Datenbank an und aktualisiert somit die Replikation.
• Replikationsslots: Diese Slots verhindern, dass der Primärserver WAL-Dateien löscht, die noch nicht vom Replikat verarbeitet wurden.

Für jede aktive Replikationsverbindung existieren vier entscheidende Log Sequence Numbers (LSNs):

• sent_lsn: Der letzte WAL-Block, der vom Primärserver gesendet wurde.
• write_lsn: Der letzte Block, der vom Replikat in den Betriebssystem-Cache geschrieben wurde.
• flush_lsn: Der letzte Block, der vom Replikat auf die Festplatte geschrieben wurde.
• replay_lsn: Der letzte Block, der vom Replikat tatsächlich in die Datenbank angewendet wurde.

Die Differenz zwischen diesen Werten zeigt die Latenz in Bytes an. PostgreSQL stellt darüber hinaus drei Zeitverzögerungsmetriken bereit:

• write_lag: Zeitspanne zwischen Senden und Schreiben in den Cache
• flush_lag: Zeitspanne bis zur Speicherung auf der Festplatte
• replay_lag: Zeitspanne bis zur Anwendung in der Datenbank

Diese Metriken bilden die Grundlage für ein effektives Replikations-Monitoring.

Kritische Metriken und Abfragen für ein HA-Dashboard

Ein zuverlässiges Hochverfügbarkeits-Dashboard muss nicht nur die Existenz von Replikaten anzeigen, sondern auch deren Zustand und Verzögerungen messen. Die wichtigsten Abfragen basieren auf drei Systemkatalogen:

• pg_stat_replication auf dem Primärserver
• pg_stat_wal_receiver auf dem Replikat
• pg_replication_slots auf dem Primärserver

Die folgende Abfrage liefert einen vollständigen Überblick über den Replikationsstatus aller verbundenen Standbys:

SELECT 
    application_name,
    client_addr,
    state,
    sync_state,
    pg_wal_lsn_diff(pg_current_wal_lsn(), sent_lsn) AS sent_lag_bytes,
    pg_wal_lsn_diff(pg_current_wal_lsn(), write_lsn) AS write_lag_bytes,
    pg_wal_lsn_diff(pg_current_wal_lsn(), flush_lsn) AS flush_lag_bytes,
    pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag_bytes,
    write_lag,
    flush_lag,
    replay_lag,
    EXTRACT(EPOCH FROM (now() - reply_time)) AS seconds_since_reply
FROM pg_stat_replication;

Für Replikate liefert pg_stat_wal_receiver essenzielle Informationen:

• conninfo: Die Verbindungseinstellungen zum Primärserver
• status: Aktueller Zustand (streaming, waiting, stopping)
• last_msg_send_time und last_msg_receipt_time: Zeitstempel der letzten Kommunikation
• latest_end_lsn: Der letzte erfolgreich verarbeitete WAL-Bereich

Die Funktion pg_last_xact_replay_timestamp() hilft dabei, die Replikationsverzögerung in Sekunden zu messen:

SELECT now() - pg_last_xact_replay_timestamp() AS replication_lag_seconds;

Replikationsslots werden durch pg_replication_slots überwacht. Besonders kritisch sind:

• wal_status: Zeigt an, ob WAL-Daten verloren gehen könnten (reserved, extended, unreserved, lost)
• safe_wal_size: Verbleibende WAL-Kapazität, bevor der Slot ungültig wird
• retained: Differenz zwischen aktuellem WAL und restart_lsn

Eine umfassende Slot-Abfrage:

SELECT 
    slot_name,
    slot_type,
    active,
    wal_status,
    pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained,
    pg_size_pretty(safe_wal_size) AS safe_left
FROM pg_replication_slots;

Häufige Produktionsausfälle und ihre Erkennung

Drei typische Szenarien führen zu unbemerkten Replikationsausfällen:

1. Replikate brechen ab – ohne Warnung

Viele Teams erkennen eine unterbrochene Replikation erst beim nächsten Failover. Mögliche Ursachen:

• Netzwerkprobleme oder Firewall-Zeitüberschreitungen zwischen Primär- und Replikatserver
• Absturz des walreceiver-Prozesses auf dem Replikat
• Ablauf der wal_receiver_timeout-Einstellung bei Netzwerkstörungen
• Falsche Verbindungseinstellungen nach einem Replikat-Neustart

Das Problem: Ein fehlendes Replikat erscheint nicht in den Logs des Primärservers. Die einzige Meldung lautet oft: terminating walsender process due to replication timeout.

Die Lösung ist ein gezieltes Alerting, das nicht nur die Anzahl der Replikate prüft, sondern ihre individuelle Verfügbarkeit:

SELECT 
    expected.name,
    CASE 
        WHEN r.application_name IS NULL THEN 'DOWN' 
        WHEN r.state <> 'streaming' THEN r.state 
        ELSE 'ok' 
    END AS health
FROM (VALUES ('replika-1'), ('replika-2')) AS expected(name)
LEFT JOIN pg_stat_replication r ON r.application_name = expected.name;

Voraussetzung für dieses Alerting ist die korrekte Konfiguration der application_name-Parameter in der Replikationsverbindung:

primary_conninfo='host=primary.example.com port=5432 dbname=postgres application_name=replika-1'

2. Replikationsslots füllen die Festplatte

Wenn ein Replikat ausfällt, aber der Replikationsslot aktiv bleibt, sammelt der Primärserver alle WAL-Dateien bis zum restart_lsn des Slots. Dies führt zu einer unkontrollierten Vergrößerung des pg_wal-Verzeichnisses und schließlich zu einem vollständigen Festplattenausfall.

Ein bekanntes Beispiel ist der Vorfall bei GitLab im Jahr 2017, bei dem ein fehlendes Monitoring der Slot-Zustände zu einer kritischen Datenbankverfügbarkeit führte.

Die Lösung besteht in der Kombination zweier Maßnahmen:

• Einstellung von max_slot_wal_keep_size (ab PostgreSQL 13), um die maximale WAL-Größe pro Slot zu begrenzen
• Überwachung des wal_status-Feldes, um frühzeitig auf gefährdete Slots zu reagieren

3. Synchronreplikation blockiert bei fehlenden Replikaten

Wenn synchronous_commit = on konfiguriert ist und das letzte synchrone Replikat ausfällt, blockiert jede Transaktion auf dem Primärserver – bis ein Replikat wieder verfügbar ist. Dies kann zu einem vollständigen Stillstand des Systems führen.

Ein effektives Dashboard muss daher nicht nur die Existenz von Replikaten überwachen, sondern auch deren Synchronisationsstatus und die aktuelle Transaktionsverzögerung.

Fazit: Replikation ist kein Selbstzweck

Eine PostgreSQL-Replikation bietet nur dann echten Hochverfügbarkeitsnutzen, wenn sie kontinuierlich überwacht wird. Ein gut konfiguriertes Dashboard kombiniert:

• Echtzeit-Metriken zu Replikationsverzögerungen
• Statusüberwachung aller Replikate und Slots
• Proaktive Alerts bei kritischen Zustandsänderungen

Nur so lassen sich Replikationsausfälle erkennen, bevor sie zu echten Ausfällen führen. Investieren Sie Zeit in die Einrichtung eines solchen Systems – bevor Ihr nächster Primärserver ausfällt und Sie feststellen, dass Ihre vermeintliche Hochverfügbarkeitslösung längst nur noch eine Illusion war.