Server Replication View — PostgreSQL
The Replication view shows how this server copies its changes to other servers, and whether that copying is healthy. PostgreSQL records every change in its write-ahead log, or WAL. A server that sends its WAL to other servers is called a primary, and a server that receives and applies that WAL is called a standby. The view works on both.
What the View Shows on a Primary and on a Standby #
This table shows what each section contains on a primary and on a standby.
| Section | On a primary | On a standby |
|---|---|---|
| Health Banner | Reports whether the standbys are replicating normally, such as "Streaming to 2 Standbys", or "No Active Replication" if there are none. | Reports whether this standby is receiving WAL from its primary, such as "Receiving from Primary" or "Not Streaming from Primary". |
| WAL Status Bar | Shows the role, WAL level, limits, and archiver status. WAL Position is the server's current position in its WAL. | Shows the same stats. WAL Position is the position of the last WAL received from the primary. |
| Connection to Primary | This section is not shown. | Shows the connection between this standby and its primary. |
| Connected Standbys | Lists the standbys that are receiving WAL from this server. | Lists any standbys that receive WAL from this standby. The list is empty unless another standby is connected to it. |
| Replication Slots | Lists the replication slots on this server. | Lists the replication slots on this server. |
WAL Status Bar #
| Stat | What it means |
|---|---|
| Role | Primary means this server accepts changes and sends its WAL to standbys. Standby means this server is read-only and applies the WAL it receives. |
| WAL Level | How much detail the server records in its WAL, set by the The possible values are minimal, replica, and logical. They are described in the PostgreSQL manual. Replication needs replica or logical. |
| WAL Position | The server's current position in its WAL. On a standby, it is the position of the last WAL the standby received. |
| Sender Limit | The most connections from standbys and backup tools that this server accepts at once, set by the max_wal_senders setting. |
| Slot Limit | The most replication slots that can exist, set by the max_replication_slots setting. |
| Archiver | Whether the server is saving copies of its WAL. It shows Off when archiving is turned off, OK when WAL files have been saved, and — when archiving is on but nothing has been saved yet. If any attempt to save a WAL file has failed, it shows the number of failures instead. That number is a running total since the statistics were last reset, so it doesn't go away when archiving starts working again. |
Connection to Primary (Standby Only) #
This section appears only on a standby. It describes the standby's connection to the primary it receives WAL from.
| Field | What it means |
|---|---|
| Status | The state of the connection to the primary. It is usually streaming, which means WAL is arriving as the primary produces it. The other possible values are described in the PostgreSQL manual. |
| Primary Host, Primary Port | The address of the primary this standby receives WAL from. |
| Received Up To | The newest WAL position the standby has received. |
| Last Heartbeat | When the primary last sent a message to this standby. If this time is old, the connection may be unhealthy. |
If the standby isn't receiving from a primary, a warning appears. The standby may be restoring from saved WAL files, or its connection to the primary may be down.
Connected Standbys #
On a primary, this section lists the standbys that are connected and receiving WAL. On a standby, it lists any standbys that receive WAL from this one in turn.
| Column | What it means |
|---|---|
| Name | The name the standby gave when it connected. |
| Address | The standby's network address. |
| State | The state of the standby's connection. It is usually Streaming, which means WAL is flowing to the standby as it is produced. The other possible states are described in the PostgreSQL manual. |
| Sync Mode | How the primary treats this standby when it commits a change. The possible values are Async, Sync, Quorum, and Potential Sync. They are described under synchronous replication in the PostgreSQL manual. |
| Applied Position | How far the standby has applied the WAL it received. Compare it with the WAL Position in the status bar. |
| Lag | The amount of WAL that the primary has sent but the standby hasn't applied yet. The number turns orange and then red as the lag grows. A standby with a large lag may show out-of-date data. |
Replication Slots #
A replication slot makes the server keep WAL until a particular consumer, such as a standby, has read it. That stops the consumer from missing changes. But if the consumer goes away, its slot keeps collecting WAL, which can fill the disk.
| Column | What it means |
|---|---|
| Name | The slot's name. Whatever reads from the slot uses this name. |
| Type | Physical slots send an exact copy of the WAL to a standby. Logical slots send individual row changes to another database or to a tool that tracks changes. |
| Plugin | The format a logical slot uses to describe changes. Physical slots have no plugin. |
| Active | Yes means something is reading from the slot right now. No means nothing is. An inactive slot still keeps WAL, so it keeps using disk space. |
| Disk Safety | How safe it is for the server to keep the WAL this slot needs. The possible values are Safe, Extended, At Risk, and Lost. They correspond to the |
| WAL Held From | The oldest WAL position the slot still needs. A very old position on an inactive slot means the server is keeping a lot of WAL for it. |
Recipes #
To check that a standby is keeping up
-
Open the Replication view on the primary and click Refresh .
-
Find the standby in Connected Standbys and check that its State is Streaming.
-
Look at its Lag.
A small number that stays small is normal. If the lag keeps growing each time you refresh, the standby is falling behind.
To find out why the primary's disk is filling up
-
In Replication Slots, look for slots where Active is No.
-
Check WAL Held From and Disk Safety for those slots.
-
If nothing needs a slot any more, drop it.
Run the
pg_drop_replication_slotfunction in the Query view. The server can't delete the WAL a slot needs until the slot is dropped or its consumer catches up.
To check that WAL archiving is working
-
Look at Archiver in the status bar. OK means WAL files are being saved.
-
If it shows a number of failures, click Refresh a few times.
A number that keeps rising means archiving is failing now. A number that stays the same may be left over from an old problem.
Refreshing #
The view doesn't refresh by itself. Use the Refresh button in the bottom bar to update it.