Replication and High Availability

The previous chapter finished with a restore that somebody had actually performed, and with a number for how long it takes. Hours is the right answer to a migration that deleted 90,000 rows and the wrong answer to a power supply that stopped. Recovering from a backup rebuilds a database; what an outage needs is a second machine that already has one. The same write-ahead log serves both, which is why these two chapters sit next to each other and why the first sentence of this one is the last sentence of that one: a replica is not a backup.

Half the machinery is already running. pg-replica-a has been streaming from pg-primary for a year and serving the analytics dashboard, and it is the reason for a symptom the team has never named: every so often an order the customer can already see on their own page has not reached the dashboard. Nothing is broken there. The replica applies the write-ahead log a fraction of a second after the primary generates it, and a page read inside that fraction gets an honest answer to a slightly older question. Naming that gap, measuring it, and deciding per query how large it may be is most of the work in the first two topics.

From there the chapter adds pg-replica-b as the failover target, prices the durability dial, meaning what a synchronous commit costs per transaction and what naming a single standby costs the whole site, and then turns to logical replication, which ships rows instead of bytes and therefore crosses major versions in a way physical replication never will. The last topic is the rehearsal: writes paused at 22:00, pg-replica-b promoted, the application reconnected, and two numbers written down along with the three things that did not work.

Topics in This Chapter