Replication, promotion, and redundancy | High Availability: design, failures, and recovery

Concept and mechanism

Replication does not always provide identical guarantees. In the PostgreSQL 18 examples, streaming replication is asynchronous by default; a standby can lag behind commits acknowledged on the primary. Being connected or accepting SELECT does not establish that all required data arrived. A lag measurement in seconds also does not independently provide an exact count of lost transactions. With synchronous replication, inspect effective configuration. synchronous_commit=remote_write confirms writing to the standby operating system without requiring durable flush on that disk. on and remote_apply establish different conditions; the latter includes replay and visibility. Latency, required acknowledgement count, and standby availability influence the behavior experienced by the application.

Guided application

PostgreSQL does not itself supply the complete external failover detection, decision, and routing system. The plan needs single authority, an appropriate candidate, promotion, and consumer reconnection. If the old primary returns, it must not resume independent writing; state and role require reconciliation through the supported procedure. In a fictional scenario, the business requires no loss of acknowledged operations but only a lagging asynchronous replica exists. The decision needs evidence and escalation of the trade-off, without promising zero loss because a deadline is close. After restoring service, confirm whether a standby exists again. A functional sole primary still has degraded redundancy, and that action must remain visible in handover.

IN PRACTICE

Completed promotion establishes neither reconnected clients nor restored redundancy.

Common pitfalls

Streaming as synchronous; remote_write as flush; reading as automatic failover; old primary as safe because of history.

Related topics: Objectives and service impact · Failure domains and residual capacity · Quorum and writer isolation

Take this idea with you

Accept recovery with validated data, authority, and consumers.

Create account

Reference: PostgreSQL 18 standby replication and commit acknowledgement · DR HA 2026-09; Pacemaker 3.0, etcd 3.6, PostgreSQL 18 and selected Kubernetes/AWS behavior