Synchronous and asynchronous replication
When a leader confirms a write decides what a failure can cost: time on every write, or the last few writes. Builds on PACELC.
5 minute lesson
When does the leader say yes
A write reaches the leader, and the leader will pass it on to its followers. The question is when the application gets its confirmation: once the leader has the write, or once a follower has it too. This one choice decides what is lost when the leader dies.
- AsynchronousConfirm now and send after
- SynchronousSend and wait and then confirm
- synchronous replication
- A write is confirmed only after other replicas have it. Reads are current, and every write waits for the network.
- asynchronous replication
- A write is confirmed first and copied to the other replicas afterwards. Writes are fast, and the other replicas lag for a moment.
Key terms
The same failure and two outcomes
Asynchronous
confirm first
- A write takes
- The leader's own time
- The leader dies
- The newest writes can be lost
- A follower dies
- The leader does not notice
Synchronous
wait for a copy
- A write takes
- Longer by a round trip
- The leader dies
- Nothing confirmed is lost
- A follower dies
- Writes wait for it
A leader replicates asynchronously. It confirms an order to the shop and, a few milliseconds later, its disk fails for good. A follower is promoted.
What can have happened to that order?
- It is gone: the follower never received it
- It is safe: the shop got a confirmation
- It is safe: followers copy before a commit
- It is doubled: both machines stored it
Show the answer
- It is gone: the follower never received it
With asynchronous replication the confirmation says only that the leader has the write. The copy is sent afterwards. If the leader is lost in the gap, the write existed on one machine, and that machine is gone. The customer saw "order placed", and the new leader has never heard of it.
With asynchronous replication a confirmed write can die with the leader.
One careful copy is usually enough
Waiting for every follower would mean that one slow or dead follower stops all writes. So systems rarely do that. The common set-up waits for one follower and lets the others run behind.
- Leaderconfirms after 1 copy
- 1 followersynchronous
- Other followersasynchronous
A leader waits for its one synchronous follower before confirming a write. That follower crashes. The leader itself is healthy.
What happens to writes, unless something steps in?
- They wait, as the confirmation never arrives
- They continue, as the leader is still healthy
- They are lost, as the follower held the data
- They go to the crashed follower's disk directly
Show the answer
- They wait, as the confirmation never arrives
The leader promised not to confirm until a copy exists, and the machine that makes the copy is gone. So every write hangs. A healthy leader has been stopped by a dead follower. Real set-ups guard against this: another follower is made synchronous automatically, or the leader is allowed to fall back to asynchronous mode.
A synchronous follower that fails stops writes. Have a second one ready to take its place.
What does synchronous replication guarantee, and what are its two costs?
Show the answer
A write is confirmed only after another replica has it, so losing the leader loses nothing that was confirmed. The costs: every write takes longer by the round trip to that replica, and if the replica is slow or down, writes wait for it. That is why systems usually wait for just one nearby follower and replicate to the rest asynchronously.
Recap
- Asynchronous: confirm at once. Fast, and the newest writes can be lost with the leader.
- Synchronous: confirm after a copy exists. Nothing is lost, and every write waits.
- The usual middle way: one nearby synchronous follower, and the others asynchronous.