PostgreSQL with Patroni: replication, quorum and safe switchover

For Linux administrators who already understand PostgreSQL access control. Build a fresh three-node PostgreSQL18 lab, let Patroni own its lifecycle, and observe WAL replay and a planned switchover. Three etcd members provide a separate majority election service. This is not an in-place migration, backup service, connection pooler or production HA certification.

Open the settings above, edit, Apply, then copy. Nodes pg1/pg2/pg3 use 10.77.18.11, 10.77.18.12, 10.77.18.13 inside 10.77.18.0/24. The exact management source is 10.77.18.50/32. PostgreSQL 5432, REST 8008, etcd client 2379 and peer 2380 must be distinct. A dedicated absolute root /srv/academy-pg18 holds this lab only; never choose an existing database, mount root or shared application directory. Cluster academy_pg18 must also be new in DCS. Inspect real routes, ownership, symlinks and listeners: syntax checks cannot establish these facts. Custom values and custom progress stay in sessionStorage for this tab/language/article/environment; default progress uses localStorage. No values enter URLs, shared links or server writes. Never enter passwords, tokens or keys. Custom examples are not executed tests.

PostgreSQL sends physical WAL from one primary to two standbys. All data nodes use the same major version, architecture, extensions and tablespace layout. Keep minor releases aligned. Patroni coordinates roles through an etcd v3 lease; it does not replicate data itself. A three-member DCS needs two votes and tolerates one member failure. A two-member DCS also needs two votes and is not a useful one-failure design.

Use three independently failing VMs/hosts and storage paths; put DCS voters across genuine failure domains. Co-locating one DCS voter on each database VM is a small lab topology, not protection from a shared hypervisor, disk, rack, power supply or network partition. Separate DCS hosts may be appropriate in production. Clients need a role-aware endpoint and reconnect/retry policy; this guide uses explicit node addresses and does not provision HAProxy or a floating IP.

The example enables Patroni synchronous_mode and synchronous_mode_strict with one synchronous standby. Acknowledged commits normally wait for a standby WAL flush; losing the synchronous partner blocks writes until a suitable replacement is selected. Latency crosses the replication link. Do not hand-edit synchronous_standby_names behind Patroni.

Asynchronous mode trades durability for availability: the promotion lag threshold is not a zero-loss promise because leader WAL position is sampled. Strict synchronous mode can sacrifice availability; forced promotion, clients overriding synchronous_commit, a cancelled commit with uncertain outcome, correlated storage loss and broken fencing still matter. Define RPO (acceptable lost work) and RTO (measured recovery interval) with the application. The ttl is not your measured RTO.

Reviewed upstream stable: PostgreSQL18.6, Patroni4.1.5, etcd3.7.2; PostgreSQL19 RC1 is not selected. PGDG supports Ubuntu26.10 stonking on amd64 only, Ubuntu26.04 resolute/24.04 noble LTS, and Debian13 trixie/12 bookworm. This walkthrough deliberately targets amd64 on every selection. Ubuntu26.10 ships Python3.14 and Patroni4.1.4; its PGDG amd64 index has no Patroni package. Other selected PGDG indexes list Patroni4.1.5. Ubuntu26.04 uses Python3.14,24.04 uses3.12, Debian13 uses3.13 and12 uses3.11. Package patches and security candidates matter; upstream classifiers alone are not a distribution support guarantee. Never use a foreign suite or PG19 binaries as fallback.