Logische Replikation überwachen (pg_stat_subscription, Apply-Fehler, Slot-Lag)

Befehl

-- Subscriber:
SELECT subname, pid, leader_pid, relid::regclass AS syncing_table, received_lsn, latest_end_lsn, now() - last_msg_receipt_time AS since_last_msg, latest_end_time FROM pg_stat_subscription;
SELECT subname, apply_error_count, sync_error_count, stats_reset FROM pg_stat_subscription_stats;
-- Publisher:
SELECT slot_name, plugin, database, active, wal_status,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS confirmed_lag,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal
FROM pg_replication_slots WHERE slot_type = 'logical';

Was es tut

Zeigt auf dem Subscriber Apply-/tablesync-Worker, empfangene und bestätigte LSN, Zeit der letzten Nachricht und kumulierte Apply-/Sync-Fehlerzahlen; auf dem Publisher das unbestätigte WAL (confirmed_flush) des logischen Slots und das insgesamt zurückgehaltene WAL.

Wann einsetzen

Beim Einrichten logischer Replikation, um bei der Umstellung eines Upgrades/einer Migration zu bestätigen, dass der Lag gegen null geht, und für das Fehler-Alerting.

Vorsicht

Ist pid NULL, läuft der Apply-Worker nicht (Subscription deaktiviert oder wiederholt fehlschlagend und neu startend); prüfe das Server-Log. Ein steigender apply_error_count weist auf einen Konflikt hin. Eine stockende Subscription sammelt auf dem Publisher WAL und catalog_xmin an; überwache Platte und Katalog-Bloat des Publishers.