liveBook · Manning

Server redundancy

As explained in PostgreSQL Mistakes and How to Avoid Them

Server redundancy is the provision of multiple database servers so service can continue when one server fails or is unavailable.

Server redundancy keeps a PostgreSQL service available by maintaining multiple database servers instead of relying on one production node. Replication allows a standby to take over when the primary fails, avoiding backup-restore delays during outages. section 9.5

A reliable design accounts for PostgreSQL’s single-primary architecture:

  • PostgreSQL cannot run two primary servers for the same databases simultaneously; failover promotes a standby to become the new primary. section 9.5
  • Use a second standby when redundancy must remain intact while another server undergoes maintenance or permanent failure. section 9.5
  • Cascading replication can reduce additional replication and backup load on the primary. section 9.5
Figure 9.3 A sample PostgreSQL HA setup with a cascaded replication for redundancy and backup
figure

Use the topology diagram to compare a primary, multiple standbys, and cascading replication in a PostgreSQL HA arrangement. section 9.5

How PostgreSQL Mistakes and How to Avoid Them covers it

How deep it goes
Explains replication, single-primary constraints, standby promotion, and cascading topology but defers detailed failover mechanisms.
Examples
Uses a three-server cascaded-replication topology and outage scenarios involving banks, trading firms, hardware, and data centers.
What you can do after
Operate/configure a PostgreSQL deployment with replicated standbys and understand why failover promotes only one new primary.
How it connects
Connects server redundancy with data replication, standby servers, failover, backups, and high availability.

This explainer was generated by Manning's knowledge graph from the text of PostgreSQL Mistakes and How to Avoid Them. The section links point to the parts of the book it draws on.