High availability (HA) keeps a database accessible through failures, from minor incidents to catastrophic events, while minimizing downtime and data loss. Treat HA as a central production deployment concern, not an emergency task after the database fails. section 9.0
The single-server trap
A PostgreSQL installation with one database server, untested backups, and no failover provision may appear reliable until an outage occurs. Replace that gamble with tested full restores, redundant backup copies, standby nodes through replication, and proven management tools rather than manual failover scripts. section 9.7
Build HA around preparation, redundancy, and verification:
- Protect recovery options with PostgreSQL recovery features, dedicated backup software such as Barman or pgBackRest, and a redundant backup copy in a second location. section 9.0 section 9.7
- Test backups by performing a full restore; automation helps, but every recovery step still requires verification. section 9.7
- Provide redundancy with standby nodes via replication, and manage failover with established tools such as RepMgr, Patroni, or CloudNativePG for Kubernetes. section 9.7
- Act before failure: test proposed improvements in a production-like staging environment and roll them out with time to spare. section 11.2
Figure 11.1 A roadmap for systematically assessing, fixing, documenting, and improving an inherited database.
Use the roadmap to assess an inherited database, prioritize repairs, document its configuration, and improve high-availability, disaster-recovery, and maintenance processes incrementally. section 11.3.3
