Each node that stores a copy of the database is called a replica. With multiple replicas, a question inevitably arises: how do we ensure that all the data ends up on all the replicas?
Every write to the database needs to be processed by every replica; otherwise, the replicas would no longer contain the same data. The most common solution is called leader-based, primary-backup, or active/passive replication. It works as follows (see Figure 6-1):
-
One of the replicas is designated the leader (also known as the primary or source). When clients want to write to the database, they must send their requests to the leader, which first writes the new data to its local storage.
-
The other replicas are known as followers (or read replicas, secondaries, or hot standbys). Whenever the leader writes new data to its local storage, it also sends the data change to all its followers as part of a replication log or change stream. Each follower takes the log from the leader and updates its local copy of the database accordingly, by applying all writes in the same order as they were processed on the leader.
-
When a client wants to read from the database, it can query either the leader or any of the followers. However, writes are accepted only by the leader (the followers are read-only from the client’s point of view).
Diagram illustrating single-leader replication where user updates are written to the leader, which replicates changes to follower replicas, while reads can occur from any replica.
Figure 6-1. Single-leader replication directs all writes to a designated leader, which sends a stream of changes to the follower replicas.
If the database is sharded, each shard has one leader. Different shards may have leaders on different nodes, but each shard must nevertheless have one leader node. In “Multi-Leader Replication” we will discuss an alternative model in which a system may have multiple leaders for the same shard at the same time.
Single-leader replication is very widely used. It’s a built-in feature of many relational databases, such as PostgreSQL, MySQL, Oracle Data Guard, and SQL Server’s Always On availability groups. It is also used in some document databases (such as MongoDB and DynamoDB), message brokers such as Kafka, replicated block devices such as DRBD, and some network filesystems. Many consensus algorithms—such as Raft, which is used for replication in CockroachDB, TiDB, etcd, and RabbitMQ quorum queues (among others)—are also based on a single leader and automatically elect a new leader if the old one fails.
Note
In older documents you may see the term master–slave replication. It means the same as leader-based replication, but the term should be avoided as it is widely considered offensive.