Hands-on Lab·PostgreSQL
PostgreSQL Replication Monitoring
The primary and the standby each have their own view, and neither is complete. Four LSNs on the primary show exactly where a lagging standby is stuck - sent, written, flushed or replayed.
Replication Guide 28 of 47 Intermediate
- OSUbuntu 26.04 LTS
- PostgreSQL18.6-0ubuntu0.26.04.1
- ReplicationPhysical streaming, async, with slots
- TimeAbout 15 min
Column names differ between the two views and between versions - pg_stat_wal_receiver has received_tli, not received_lsn. Check \d on the view rather than trusting a remembered query.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| db-a01 | 192.168.0.81 | Ubuntu 26.04 LTS | Primary / Source / Replica Set Member 1 | 2 Core | 4 GB | 50 GB |
| db-c01 | 192.168.0.83 | Ubuntu 26.04 LTS | Replica Set Member 3 / Cascading and Delayed Replica | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when you need to know whether a standby is keeping up. This matters because the primary and the standby each hold half the picture - and neither view is complete on its own.
- looking from the primary, through
pg_stat_replication - looking from the standby, through
pg_stat_wal_receiver - reading the settings the standby is actually using
- measuring lag under load, from both sides at once
Before you start
- A streaming standby.
-
Look from the primary
-
Look from the standby
-
Read the settings the standby is using
-
Measure lag under load