Hands-on Lab·PostgreSQL
PostgreSQL Streaming Standby Creation
One pg_basebackup -R builds the standby, writes its connection settings and drops a standby.signal file. Start it and it streams - and refuses writes, which is the opposite of what a fresh MySQL replica does.
Replication Guide 27 of 47 Advanced
- OSUbuntu 26.04 LTS
- PostgreSQL18.6-0ubuntu0.26.04.1
- ReplicationPhysical streaming, async, with slots
- TimeAbout 17 min
standby.signal replaced recovery.conf in PostgreSQL 12. Documentation mentioning recovery.conf is describing a file that no longer exists.
| 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-b01 | 192.168.0.82 | Ubuntu 26.04 LTS | Standby / Replica / Replica Set Member 2 | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when a streaming standby has to exist. This matters because one pg_basebackup -R copies the cluster, writes its connection settings and marks it as a standby - and the standby then refuses writes, which is the proof it worked.
- emptying the standby, and copying the primary onto it
- seeing the two things that one
-Rflag wrote for you - starting it, and confirming what Debian reports it as
- proving replication, then trying to write and being refused
Before you start
- The prerequisites guide completed - role, rule and slot.
- A second host whose data you are willing to destroy.
-
Empty the standby and copy the primary onto it
-
See what -R wrote
-
Start it and confirm what it is
-
Prove replication, then try to write