Replication

Sync vs async replication, stale reads and what a failover loses.

On the roadmap:Intermediate · step 2: Replication

Intermediateabout 10 to 15 min6 experiments

Experiments

New here? A few short steps show what happens, one at a time.

Settings

When does the leader say “done”?

Replication lag (ticks)3

Followers2

If the leader fails, promote

Client was told safe

In flight

0 messages

Stale reads

none yet

Writes lost at failover

no failover yet

Press Write, then Tick, and try reading from a follower or crashing the leader before the followers catch up.

Reading from followers: how often is it stale?

Each read goes to a random follower. Spreads the load best, but a user can read from one that has not yet seen their own write.

Stale reads

30%

Missed own write

Reads on the leader

reads that were stale

Any followerAlways the leaderLeader just after a write

A simulated user writing and reading at random, in the current replication mode with the current number of followers. More lag means more stale reads from followers; reading from the leader avoids them but gives up read capacity.

In plain words

Replication keeps copies of the same data on several machines. One machine, the leader, takes the writes and passes them to followers. How long the leader waits for the followers before telling the client 'done' is the choice you tune.

Why it matters

Copies protect you when a machine fails and let reads be spread out. But the copies drift apart while a write is travelling, and the leader's answer to the client can get ahead of the followers. That gap is where stale reads and lost writes come from.

How real systems do it

The simulation is a simplified model. Here is what production systems add or do.

PostgreSQL and MySQL replicate asynchronously by default and offer stricter modes. PostgreSQL's synchronous_commit can make a commit wait for a standby to receive or flush it, and MySQL's semi-synchronous replication waits until at least one replica has acknowledged receiving the transaction.
MySQL's semi-synchronous mode falls back to asynchronous if no replica answers before its timeout, so it narrows the risk of losing writes rather than removing it.
After a leader fails, the new leader should be the most up-to-date replica. Choosing a stale one loses writes that clients were told had succeeded.
A common remedy for stale reads is to send a user's own reads to the leader for a short time after they write, so they always see their own changes.