A Redis Cluster primary that owns a range of hash slots has been marked as failed. Describe how one of its replicas becomes the new owner of those slots.

## Precondition Nothing starts until the failed primary is in the **FAIL** state — the cluster-wide agreement reached when a majority of slot-owning primaries have reported it as unreachable. A replica never promotes itself merely because it lost its own link to the primary; that would be exactly how a network problem turns into two primaries for one slot range. ## Step 1: eligibility A replica disqualifies itself if its data is too old to be trustworthy. The rule is based on how long its replication link to the primary had been broken before the failure: if that disconnection exceeds roughly `cluster-node-timeout × cluster-replica-validity-factor` (default factor 10) plus the ping period, the replica will not campaign. Setting the factor to 0 disables the check, which maximises availability — some replica will always try — at the cost of possibly promoting a badly stale one. This is a real availability-versus-consistency dial. ## Step 2: the ranked delay Eligible replicas do not campaign immediately. Each computes a delay of roughly: ``` 500 ms (fixed) + random 0-500 ms + rank * 1000 ms ``` The fixed part gives the FAIL state time to propagate cluster-wide so voters agree the primary is gone. The random part decorrelates simultaneous campaigns. **Rank** is the replica's position when the primary's replicas are sorted by replication offset, best first: the most up-to-date replica has rank 0 and therefore campaigns first, and it usually wins before the others start. Rank is recomputed as offsets are learned, so a replica that catches up improves its position. This is how Redis biases toward minimal data loss without an explicit "who has the most data" negotiation. ## Step 3: requesting votes The campaigning replica increments the cluster's `currentEpoch` — a monotonically increasing logical clock shared by the cluster — and broadcasts a failover authorisation request stamped with that epoch. A primary grants a vote only if all of the following hold: it serves at least one hash slot; it has not already voted in this epoch; the requester is a replica of a primary currently in the FAIL state; and the request's epoch is not stale. Each voter replies with an acknowledgement. Voters also refuse to vote again for the same failed primary's replicas for a short cooldown, which prevents rapid re-elections from thrashing. Because votes come only from slot-owning primaries and a **majority** is required, a minority partition can never authorise a promotion — the same quorum property that governs FAIL detection. ## Step 4: taking over On winning, the replica: 1. Adopts a new `configEpoch` — the highest so far — which is the tiebreaker for configuration conflicts. 2. Turns itself into a primary and claims all hash slots previously served by the failed node. 3. Advertises the new configuration in its PING/PONG payloads, so the rest of the cluster converges. Configuration conflicts are resolved by **highest config epoch wins**: when the old primary comes back and claims the same slots with an older epoch, every node — including itself — recognises the newer claim, and the old primary demotes itself to a replica of the node that replaced it. Its remaining sibling replicas also re-point to the new primary. Thanks to replication ID handoff (PSYNC2), those replicas can often continue with a partial resynchronisation instead of a full one, avoiding a fork-and-transfer storm right after a failover. ## Manual failover `CLUSTER FAILOVER`, run on a replica, does the same handover deliberately and **without data loss**: the primary pauses clients, the replica waits until it has caught up to the primary's exact offset, and only then does the promotion proceed. Two overrides exist for emergencies: `FORCE` skips the coordination with a primary that is unreachable but still runs the normal election, and `TAKEOVER` skips the election entirely and unilaterally seizes the slots with a bumped epoch. `TAKEOVER` can produce data loss and a divergent history; it is a last resort, not an operational routine. ## Replica migration After a failover the promoted primary may be left with no replica, while some other primary has two. Redis handles this with **replica migration**: a primary with spare replicas donates one to an orphaned primary, subject to `cluster-migration-barrier` (default 1 — never donate if it would leave the donor with fewer than one replica). This is why an odd extra replica in the cluster is genuinely useful: it self-heals coverage after a promotion. ## Timing summary Detection (up to `cluster-node-timeout`) + FAIL agreement propagation + the ranked delay (roughly 0.5-2 s for the best replica) + slot claim + client topology refresh. Only the failed shard's slots are affected; the rest of the cluster keeps serving throughout.