Skip to main content
Scalingchapter 3 of 4 · 4 lessons

Database Replication

Copy data across multiple DB nodes for reads and high availability.

Your database is one machine. At 03:40 on a Sunday its disk controller fails.

Everything stops, and it stays stopped until somebody wakes up, finds last night's backup, and restores it onto new hardware. That is four hours if the runbook is good, and you have lost every order placed since the backup ran.

Replication is keeping a second machine that already has the data, applying every change as it happens. It also scales your reads and puts data nearer your users, and those are the bonuses. The reason you do it is the Sunday.

The catch is that copies drift, and almost all the engineering here is about how much drift you can stand.

Lessons

4 in this chapter
  1. Leader-Follower BasicsAll writes go through one door. Everything else is copies replaying the leader's log.2 min
  2. Sync vs Async ReplicationDoes the leader wait for a follower before saying done? That decides what a crash can eat.2 min
  3. Replication Lag in PracticeReplicas run behind by design, and users notice the moment they read their own missing write.3 min
  4. Failover and Multi-LeaderPromoting a follower is easy. Fencing the old leader and merging conflicts is the hard part.3 min