14. Replication
1
The picture to keep in your head2
14.1 Why keep copies of the same data?3
14.2 How does leader-follower replication work?4
14.3 Should the leader wait for followers before confirming a write?5
14.4 What is replication lag, and why does it happen?6
14.5 How do you stop lag from confusing users?7
14.6 How do you use read replicas in practice?8
14.7 What happens when the leader fails?9
14.8 What is split brain, and how is a leader safely chosen?10
14.9 When would you have more than one leader?11
14.10 How does leaderless replication work, and what are quorums?12
Memory card and where the analogy breaks13
Practice: five levels14
Interview questions15
Solutions16
Sources17
Code lab14. Replication
14.6 How do you use read replicas in practice?
3 min read+10 XP
At the bank: Most customers just read notices, so the bank opens more branches for reading. Anything that changes an account still goes to head office.
In the system: Read replicas take read traffic off the leader:
- Route by the kind of query: writes and read-after-write reads go to the leader; everything that can be slightly stale (book pages, search, recommendations, reports) goes to replicas. This is usually done in the app (separate connection pools) or by a database proxy.
- Size them like any fleet (Chapter 2): if each replica handles 5,000 reads a second at full load and you keep them at 70%, 20,000 reads a second needs about 6 replicas.
- Give heavy jobs their own replica: analytics and nightly reports on a dedicated replica, so a huge query doesn't slow users' reads or make the user-facing replicas lag.
- Remove a lagging replica from rotation automatically.
- Remember the limit: replicas don't help writes. If the leader is saturated by writes, you need a bigger leader or sharding (Chapters 6 and 15).
Memory code: "Reads to the branches, changes to head office."