Course outline · 0% complete

0/29 lessons0%

Course overview →

Replication: leader and followers

lesson 4-2 · ~10 min · 12/29

One database is a single point of failure

Unit 2 gave you many app servers, but they all talk to one database box. If its disk dies, your product and its data are gone. That is unacceptable, so databases are replicated: full copies kept on multiple machines.

The standard arrangement is leader-follower (also called primary-replica):

  • The leader is the only node that accepts writes
  • Every write is recorded in an ordered replication log, and each follower replays that log to stay a faithful copy
  • If the leader dies, a follower is promoted to be the new leader, a process called failover

Why one leader? If two nodes accepted writes independently, they could both change the same row at once and disagree forever. Funneling writes through one node sidesteps that conflict entirely. You pay for it with a write ceiling, which unit 5 addresses.

Leader (writes)Follower 1Follower 2replays the logreplays the log
Writes go to the leader. The replication log streams every change down to the followers, which replay it in order.

Code exercise · python

Run this replication log replay. The leader records every write in order, and a follower applies them one by one. Order is the whole trick: because both apply the same log in the same order, the follower ends as an exact copy.

Quiz

In a leader-follower setup, why do all writes go through the single leader?

Problem

Your leader database dies. Automated failover detects the failure after 10 seconds and takes 20 more seconds to promote a follower. Writes fail during the whole episode. How many seconds of write downtime did users experience?