Raft Cluster Membership Change Protocol
Related Posts:
- Raft Consensus Protocol Made Simpler [link]
- Raft Cluster Membership Change Protocol [this one]
- Raft Consensus Protocol Implementations [link]
Background
In my first blog post about Raft — Raft Consensus Protocol Made Simpler, I promised I’d write about Raft cluster membership change. That’s too important a topic to omit. Due to various administrative reasons, new nodes may need to be added to the cluster, existing nodes may need to be removed or replaced. A mature and practical consensus protocol has to address the need to update cluster membership. In this blog post, let’s see how Raft does it. This blog post relies extensively on the knowledge built in that first blog post. It’s strongly recommended that you at least skimmed through that before diving into this one.
Cluster Membership Change
Cluster membership update is surprisingly easy once you understand the fundamentals of Raft’s log replication and leader election. Diego initially designed a more complex algorithm but later discovered it could be largely simplified if we impose a restriction: only one node change at a time — either add or remove. It’s a realistic simplification because clusters typically run in 3-node-mode, 5-node-mode, or occasionally 7-node-mode. Changes among them require only a handful of sequential one-time cluster membership updates.
