Module 13 / Replication

Module 13 · lesson 5 of 9 · Read 10 min

Consensus: agreeing on a log

Raft and Paxos in one lesson, and what they cost.

The last lesson made one leader safe with a majority vote and a term number. But choosing a leader is only half the job. The new leader also has to hold every write the old one confirmed, and every replica has to apply those writes in the same order. Getting a group of machines to agree on that, while any of them can crash and any message can be lost, is called consensus.

You'll lean on consensus all through this part of the course, usually without building it: etcd and ZooKeeper, Kafka's controller, CockroachDB, Spanner and the lock services from Module 12 all run on it. This lesson gives you the working mechanics of Raft and Paxos in one sitting, enough to reason about what they promise and what they cost. Module 19 traces both message by message.

What consensus promises

Consensus gets a group of nodes to agree on one ordered log of commands. Once an entry is committed, it is never lost or changed, and every node applies the log in the same order.

That second sentence is the useful part. If every node starts from the same state and applies the same commands in the same order, every node ends up in the same state. This is called state machine replication, and it turns "agree on a log" into "agree on a database", a lock table or a cluster's configuration.

There are two promises, and they behave differently under failure:

  • Safety: nothing committed is ever lost, and no two nodes ever disagree about what's at a given position. This holds always, whatever crashes, delays or partitions happen.
  • Progress: new entries get committed as long as a majority of nodes are up and can talk to each other. Lose the majority and the group stops accepting writes. It doesn't make anything up.