How the Redis Sentinel cluster works and what happens on failover

Understand the master/replica replication model, how Sentinel monitors Redis health, and what the automatic failover process looks like.

Master / replica replication

The Redis cluster runs one master and one or more replicas. All writes go to the master. The master asynchronously replicates every write to the replicas. Replicas serve read traffic, which reduces load on the master. In normal operation the master and replicas are in sync within milliseconds.

What Sentinel does during normal operation

Three Sentinel processes run continuously, each in its own container. Every second, each Sentinel pings the Redis master and replicas. As long as the master responds, Sentinels report it as healthy and do nothing.

Sentinel quorum and subjective / objective failure

When a Sentinel cannot reach the master for more than the configured timeout (default 5 seconds), it marks the master as subjectively down (SDOWN). It then broadcasts this to the other Sentinels. When a quorum of Sentinels (2 out of 3) agree the master is unreachable, it is declared objectively down (ODOWN) and a failover is triggered.

What happens during a failover

One Sentinel is elected leader for the failover. The leader: 1. Picks the most up-to-date replica as the new master 2. Sends a REPLICAOF NO ONE command to promote it 3. Updates the other replicas to replicate from the new master 4. Broadcasts the new master's address to all Sentinels 5. Adds the old master (if it recovers) as a replica of the new master

This entire process typically takes 10–30 seconds.

How the app reconnects after failover

The app does not connect directly to the Redis master's IP address. Instead it connects to a Sentinel node and asks "who is the current master?". After a failover, the Sentinel responds with the new master's address. The Redis client library handles this automatically using the Sentinel protocol — no app restart is required.