Replication and High Availability
Streaming replication
A standby continuously replays WAL from a primary. The primary needs wal_level=replica (or logical), max_wal_senders, and a pg_hba.conf entry permitting the replication connection; the standby needs a standby.signal file and primary_conninfo. pg_basebackup -R writes both for you. A hot standby is read-only and can serve SELECT queries.
Sync versus async
Asynchronous replication can lose recent commits during failover. Synchronous replication is driven by synchronous_standby_names together with synchronous_commit (on, remote_write, remote_apply, local, off). A frequent trap: synchronous_commit=on only guarantees local WAL flush - it is not the same thing as synchronous replication.
Replication slots
A physical or logical slot stops the primary from removing WAL a consumer still needs. That is also the danger: an abandoned slot fills pg_wal and can take the server down. Watch pg_replication_slots (active, restart_lsn) and cap growth with max_slot_wal_keep_size.
Logical replication
Publications and subscriptions replicate row changes for selected tables. They require wal_level=logical and do not carry DDL, sequences, or schema; initial data needs a manual copy or CREATE SUBSCRIPTION ... COPY_DATA.
Monitoring and failover
On the primary, pg_stat_replication reports state, sent_lsn, write_lsn, flush_lsn, replay_lsn and lag; on the standby, pg_stat_wal_receiver. Promote with pg_ctl promote, and use pg_rewind to rejoin a former primary. Every promotion advances the timeline.
Rule of thumb
Synchronous replication protects committed data; replication slots protect WAL. Monitor slot lag and size max_slot_wal_keep_size so a stale subscriber cannot exhaust the disk.