Exercise 3: Why Replication Is Not a Substitute for Backups — Possible Solution ==================================================================== THE CHAPTER'S OWN WARN-BOX ------------------------------ Per this chapter's own warn-box, "a mistake or an accidental deletion on the primary replicates to every standby just as faithfully as a legitimate change does — replication protects against hardware or server failure, not against data corruption or accidental deletion." THE SPECIFIC MECHANISM THAT MAKES THIS TRUE ------------------------------ Per this chapter's own earlier material, streaming replication works by "continuously shipping WAL records from a primary server to one or more standby servers, which replay those records to stay in sync." The replication mechanism has no concept of "good" changes versus "bad" changes — it faithfully ships and replays EVERY WAL record generated on the primary, without any distinction between a legitimate application UPDATE and an accidental DROP TABLE or a destructive bug-triggered DELETE. Because the mechanism's entire job is to keep every replica in sync with the primary's own current state, a destructive change is, by definition, propagated with exactly the same speed and fidelity as any other change — replication cannot tell the difference between the two. WHY THIS MEANS REPLICATION SOLVES A DIFFERENT PROBLEM ------------------------------ Replication exists to protect against a specific category of failure: hardware dying, a server crashing, a data center going offline — scenarios where the DATA ITSELF on the primary was still correct, but the primary as a piece of infrastructure became unavailable. A replica lets another server pick up serving that same, still-correct data. But if the data itself becomes wrong (via accidental deletion or corruption), every replica ends up holding that same wrong data within moments, since propagating changes accurately — including bad ones — is exactly what replication is designed to do. WHY BACKUPS REMAIN A SEPARATE, NECESSARY PRACTICE ------------------------------ Per this chapter, "real backups remain a separate, necessary practice no replication setup replaces." A backup, unlike a replica, captures a POINT-IN-TIME snapshot that is deliberately NOT kept continuously in sync with the primary's every subsequent change — which is exactly what allows a backup to still hold the correct, pre-mistake data even after a destructive change has already propagated to every live replica. Recovering from an accidental deletion means going back to a backup taken before the mistake happened, not to any replica, since every replica already has the mistake too. WHY THIS WORKS AS AN ANSWER ------------------------------ It explains precisely why the replication mechanism itself (faithful, indiscriminate WAL shipping) is what makes it incapable of protecting against data corruption, and explains what property a backup has (point-in-time separation from ongoing changes) that a replica structurally lacks.