Leaders and followers

Replication keeps the same data on several networked machines. In this chapter, every machine holds the whole dataset.

Why replicate

Copies put data close to users, keep the system running when a machine dies, and share the reads. Copying data once is easy; the hard part is keeping copies in step as it changes. Almost every distributed database uses one of three styles: single-leader, multi-leader, or leaderless. Replication does not replace backups. A mistaken delete reaches every replica, but a backup lets you go back in time.

Leader and followers

One replica is the leader, and every write goes to it. The leader writes locally, then sends each change on a replication log to the followers. Followers apply changes in exactly the leader's order. Reads can go to any replica. With shards, each shard has its own leader.

Sync vs async replication

For a synchronous follower, the leader waits for its confirmation before telling the client "done". For an asynchronous one, it does not wait. Lag is usually under a second but has no upper limit. If a sync follower stops answering, writes block, so all-sync is impractical. Semisynchronous setups keep one sync follower and the rest async. Fully async keeps writing through any lag, but a confirmed write can be lost if the leader dies.

New and recovering followers

A plain file copy sees data changing mid-copy. Instead, take a snapshot tied to an exact log position, copy it, fetch every change after that position, then stream live changes. A follower that was down asks the leader for everything after its last applied change. After a very long outage, that log may be gone, so it starts from a backup.

Databases on object storage

Object stores are cheap, durable, and replicated, and their conditional writes can support leader election. But they are slow, charge per request, and often keep objects immutable. Designs include tiered storage, a separate fast log store, and zero-disk nodes that only cache.

Remember

• Replicas copy mistakes too; keep backups.
• One leader takes writes; followers apply them in order.
• Sync can block; async can lose confirmed writes.
• New followers start from a snapshot plus a log position.