Redis Cluster vs Sentinel

Introduction¶

Two different Redis HA stories:

• Sentinel — one dataset, one primary + replicas, automatic failover. Everything fits in one node's RAM.
• Cluster — data sharded across multiple primaries (each with replicas), automatic failover per shard. For datasets bigger than one node, or write throughput beyond one node.

Sentinel¶

A separate set of Sentinel processes (run 3 or 5, on different hosts) that:

• Monitor the primary and replicas.
• On primary failure, agree (quorum) that it's down, elect a new primary from the replicas (REPLICAOF NO ONE), reconfigure the others, and update clients.
• Serve as a discovery service — clients ask Sentinel "who is the primary for mymaster?" and connect there.

# sentinel.conf
sentinel monitor mymaster 10.0.0.11 6379 2      # quorum 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

Client requirement: a Sentinel-aware client (Jedis/Lettuce, redis-py, ioredis, go-redis all support it). The client connects to Sentinels, gets the current primary, and re-queries on connection errors.

Failover takes ~down-after-milliseconds + election (a few seconds). Writes to the old primary during the window are lost (async replication). min-replicas-to-write can make the primary refuse writes if replicas are missing — bounded loss vs availability trade-off.

Cluster¶

• 16384 hash slots distributed across primaries. A key's slot = CRC16(key) mod 16384. Each primary owns a range of slots.
• Clients connect to any node; if they hit the wrong one for a key they get a -MOVED <slot> <ip:port> redirect (learn and cache the map) or -ASK during a slot migration.
• Each primary has 1+ replicas; a primary failure triggers a replica promotion for that shard's slots (needs a majority of primaries reachable to agree).
• Minimum realistic setup: 3 primaries + 3 replicas (6 nodes). Fewer and you can't tolerate a failure while keeping quorum.

redis-cli --cluster create \
  10.0.0.11:6379 10.0.0.12:6379 10.0.0.13:6379 \
  10.0.0.21:6379 10.0.0.22:6379 10.0.0.23:6379 \
  --cluster-replicas 1

Client requirement: a cluster-aware client that follows MOVED/ASK and knows the slot map.

Multi-key operations¶

MGET a b c, transactions, Lua scripts, SUNIONSTORE — all keys must be in the same slot or you get CROSSSLOT. Use hash tags: {user:123}:profile and {user:123}:sessions hash on user:123 → same slot. Design keys around this or you can't do multi-key ops in Cluster.

Choosing¶

Most workloads that "need Redis Cluster" actually fit in one large node (hundreds of GB of RAM is available). Reach for Cluster when you genuinely outgrow a node or need to scale writes.

Verification and troubleshooting¶

# Sentinel
redis-cli -p 26379 sentinel master mymaster
redis-cli -p 26379 sentinel replicas mymaster
redis-cli -p 26379 sentinel ckquorum mymaster

# Cluster
redis-cli --cluster check 10.0.0.11:6379
redis-cli -c -h 10.0.0.11 cluster info        # cluster_state:ok
redis-cli -h 10.0.0.11 cluster nodes
redis-cli -h 10.0.0.11 cluster slots

• Sentinel: failover doesn't happen — quorum not met (fewer Sentinels reachable than quorum), Sentinels can't reach the replicas to promote, or down-after-milliseconds not elapsed. SENTINEL ckquorum.
• Sentinel: client still hits the old primary — non-Sentinel-aware client, or the client caches the address and doesn't re-query on error. Configure the client with the Sentinel list, not a fixed host.
• Cluster: CLUSTERDOWN Hash slot not served — a shard's primary and all its replicas are down, or slots aren't fully assigned (--cluster fix). cluster info shows cluster_state:fail.
• Cluster: MOVED on every request — the client isn't cluster-aware (using a plain client), or you connected with redis-cli without -c.
• Cluster: CROSSSLOT Keys ... don't hash to the same slot — multi-key op across slots. Add hash tags {...} to co-locate related keys.
• Cluster: split-brain after a partition — a minority partition's primaries stop accepting writes (they can't get quorum); the majority side promotes replicas. When healed, the old primaries become replicas. Writes to the minority side during the split are lost.
• Uneven shard load — one hash tag or key family dominates a slot range. Reshard, or fix the key design (a hot {global} tag defeats sharding).

Related tools and reading¶

• On-site: Port Checker.
• Related posts: Redis persistence: RDB vs AOF, Redis as a cache: maxmemory and eviction policies.