Redis Cluster Failover Lifecycle Visualization

Redis Cluster keeps the database available by distributing 16,384 hash slots among primary nodes and replicating each primary to a replica. This walkthrough models the native Cluster path: cluster-bus failure reports establish FAIL, a replica obtains primary authorization for a new epoch, and the promoted primary publishes unchanged slot-range ownership before clients recover with MOVED.

Mental Model

A client hashes a key with CRC16 and uses its slot map to reach the primary that owns that slot. In the walkthrough, slot 4096 belongs to Primary A’s 0–5460 range. Primary B and Primary C own the other two ranges, making a three-primary topology. If Primary A fails, its Replica A must preserve that exact 0–5460 range when it promotes; the owner changes, but the slot assignment does not.

Components and Why They Exist

Client and Slot Map

The client computes a key’s slot and caches the primary responsible for it. The cache makes normal requests direct. After a configuration change, a stale cache can send slot 4096 to Primary A and receive MOVED 4096 replica-a; it then updates its map and retries at Replica A.

Primary A, Primary B, and Primary C

The three primaries own aligned, non-overlapping ranges: Primary A owns 0–5460, Primary B owns 5461–10922, and Primary C owns 10923–16383. Primary B and Primary C are independent reporters and voters when Primary A is unreachable. Their two reports are a real 2 / 3 primary majority, not a quorum inferred from a single healthy peer.

Replica A

Replica A streams Primary A’s writes before the failure. Once the cluster disseminates FAIL, it requests authorization for a new failover epoch. It becomes primary only after Primary B and Primary C authorize that epoch. On promotion, it takes over Primary A’s entire 0–5460 range, including slot 4096.

Cluster Bus Health Evidence

Cluster nodes use PING/PONG and gossip to exchange failure evidence. A missing PONG causes each observer to mark PFAIL locally. PFAIL is not a global verdict: Primary B’s report alone is insufficient. When Primary C independently reports PFAIL too, the two healthy primaries provide the 2 / 3 majority that disseminates FAIL for Primary A.

Election Epoch and Configuration Propagation

Authorization acknowledgements are scoped to an epoch, so a primary votes only for one candidate in that election. After Replica A receives Primary B and C’s FAILOVER_AUTH_ACK messages, it promotes with config epoch 8 and advertises ownership of 0–5460. That higher epoch is the configuration clients converge on.

Edge Cases and Misconceptions

PFAIL Is Local; FAIL Is Cluster-Wide

PFAIL records one node’s timeout observation. It does not itself permit promotion. FAIL is disseminated only after the required majority of primary reports, so a transient or isolated observation cannot trigger the modeled failover.

Authorization Is Separate From Failure Reports

The same healthy primary set can report the failure and then authorize the candidate, but these are distinct messages and stages. The replica needs a majority of epoch-scoped authorizations before it can claim the failed primary’s slots.

Slot Ownership Does Not Move to a Different Range

Failover changes the owner of Primary A’s range, not the range itself. The final configuration remains 0–5460, now owned by Replica A. A client follows the permanent MOVED target for slot 4096 and retries there; ASK is instead reserved for temporary resharding redirects.