OpenACID Blog
OpenRaft now skips joint consensus when every old quorum intersects every new quorum. A linear-time test identifies exactly when this is safe for majority-based configurations. It covers Raft’s familiar one-node-at-a-time changes and a few additional cases, while retaining joint consensus for changes that need it.
Standard joint consensus provides its own log barrier through config entries. Single-step changes and joint consensus extended with rollback require a committed current-term entry before a new config. Two failure scenarios show why the difference comes down to quorum overlap.
A Raft leader usually waits for a majority before committing a write. We can reduce that wait, but the election rules and leader identities must still protect the log. Through a few small clusters, we explore two ways to do this, then follow the consequences for reads, failures, and membership changes.
Raft’s single-server membership change carries two problems: its middle state can turn one datacenter into a single point of failure, and the original algorithm could lose a committed entry. Let us look at membership change through quorum sets, and see why joint consensus is the answer.
Raft 在单步成员变更的设计上存在缺陷, 一定要抛弃单步变更, 使用joint consensus