Reference · Cheat sheet

Sentinel & Cluster

Automatic failover, and sharding by hash slot. Print it, pin it.

From lesson 0007See also glossary

Sentinel — HA for one primary

Four jobs: monitoring · notification · automatic failover · configuration provider (clients ask it "who's the primary?").
Distributed: run an odd number ≥ 3 cooperating Sentinels — no SPOF.
SDOWN: one Sentinel subjectively suspects the primary (missed PINGs).
ODOWN: ≥ quorum Sentinels agree → objectively down.
Two gates: quorum only detects; a majority of Sentinels must elect a leader to actually fail over → minority partition can't promote.
Result: replica promoted, others reconfigured, clients told the new address.

Cluster — HA + horizontal sharding

16384 hash slots; HASH_SLOT = CRC16(key) mod 16384.
Each primary owns a subset of slots (each shard = primary + replicas, own failover).
Resharding moves slots between nodes — no downtime.

Redirect	Meaning	Client action
`-MOVED`	slot permanently elsewhere	update slot map, retry (and future keys)
`-ASK`	slot migrating now	`ASKING` + retry this query only

Gotchas

Multi-key across slots → CROSSSLOT error. Force one slot with a hash tag: only the substring in { } is hashed, so {u1}:a and {u1}:b share a slot.
Not strongly consistent: async replication per shard → can lose acked writes. A primary that can't reach the majority stops accepting writes after node-timeout.

Which?

Sentinel: data fits one node, you just need failover. No multi-key limits.
Cluster: data/writes exceed one node. Multi-key needs same-slot (hash tags).

← lesson 0007 · Sources: Sentinel · Scaling · Cluster spec