Overview & Architecture

Redis ships with replication and a dedicated high-availability companion — Sentinel — but they are two separate pieces you assemble yourself. Replication alone gives you copies of your data; it does not promote a replica when the primary dies. Redis Sentinel is the part that watches the primary, agrees by quorum that it is down, promotes a replica automatically, and then tells your clients where the new primary is.

Replication — one primary (read/write) and N replicas (read-only) kept in sync asynchronously.
Sentinel — a separate process that monitors the primary and replicas, detects failure by quorum, runs the leader election, promotes a replica, and reconfigures the others to follow it.
Sentinel-aware clients — applications ask any Sentinel "who is the master?" and connect there. When a failover happens they are notified and reconnect to the new primary — no proxy or virtual IP required.

Architecture

Redis Sentinel architecture: a Sentinel-aware client discovers the primary; primary replicates to two replicas; three Sentinels monitor and form quorum

Layer	Component	Role
Data	Redis 8 (primary + 2 replicas)	The keyspace + asynchronous replication
Detection & election	Redis Sentinel (3 instances)	Quorum, automatic promotion, reconfiguration
Discovery	Sentinel-aware client	Asks Sentinel for the current primary

What we will build

A 3-node Redis cluster — one primary plus two replicas — where every node also runs a Sentinel:

redis-sv01, redis-sv02, redis-sv03 — each runs redis-server and redis-sentinel

Co-locating the Sentinels on the data nodes keeps the build to three machines while still giving Sentinel its required odd number (3) for quorum. Three is the minimum for a real cluster: a quorum of 2 survives the loss of one node, and the odd count avoids split-brain.

Why no load balancer? Unlike a database behind HAProxy, Redis clients are Sentinel-aware — they discover the primary directly. Putting a TCP proxy in front would hand clients a fixed address and defeat that discovery. The Sentinels are the routing layer.

The end result

When the primary fails, the Sentinels agree it is down, elect a leader among themselves, promote a replica, and reconfigure the rest — in a few seconds. Clients re-resolve the primary through Sentinel and carry on. We prove exactly that with a hard-kill failover test, and watch the old primary rejoin automatically as a replica.

Heads-up: every password in this guide is a placeholder. Replace them all with your own strong secrets before using this anywhere real.