What is Redis Sentinel?

A single Redis or Valkey server is a single point of failure. The moment that master node goes down, every application that depends on it starts throwing errors, and someone has to notice, pick a replica, promote it, and repoint every client — usually at 3 a.m. Redis Sentinel exists so that nobody has to do that by hand.

This guide explains what Redis Sentinel is, how it delivers high availability, how to run and configure it, and how to connect to it from Java so your application rides out a failover without missing a beat.

Redis Sentinel at a Glance

Redis Sentinel is the high-availability system that ships with Redis (and works the same way with Valkey). It sits alongside your Redis deployment and does three jobs: it monitors your master and replica nodes, it notifies you when something looks wrong, and — most importantly — it performs automatic failover, promoting a replica to master when the current master fails.

Sentinel does not store your data and it does not shard it. It is a supervisor process. You run a small cluster of Sentinel instances whose only responsibility is to watch a master/replica group, agree on when the master has died, and orchestrate the promotion of a healthy replica in its place. Clients then discover the new master through Sentinel rather than being hard-coded to a fixed address.

In short: Sentinel turns a master-replica setup into a self-healing one.

How Redis Sentinel Works

Understanding the failover mechanism is what separates a working deployment from one that quietly does the wrong thing under load. Here is the sequence.

Monitoring. Every Sentinel continuously pings the master, its replicas, and the other Sentinels. As long as the master replies within the configured window, everything is considered healthy.

Subjectively Down (SDOWN). When a single Sentinel stops getting valid replies from the master for longer than down-after-milliseconds, that one Sentinel marks the master as subjectively down. This is just one node's opinion — it is not yet enough to act on, because the problem could be a network blip between that Sentinel and the master rather than a real outage.

Objectively Down (ODOWN). Sentinels ask each other whether they also consider the master down. Once the number of Sentinels that agree reaches the configured quorum, the master is flagged objectively down. Now it is a shared decision, not a lone vote.

Leader election. Reaching ODOWN authorizes a failover, but only one Sentinel should run it. The Sentinels elect a leader among themselves using a Raft-style vote. Crucially, electing a leader requires a majority of all Sentinels, not just the quorum — which is exactly why an odd number of at least three Sentinels matters. This majority requirement is what protects you from split-brain, where two halves of a partitioned system each try to promote a different master.

Promotion. The elected leader selects the best replica to promote — preferring the replica with the lowest replica-priority value (in Redis, a lower number means a more preferred replica), then the most up-to-date replication offset, with the lexicographically smallest run ID as the final tiebreaker. It promotes that replica to master, reconfigures the remaining replicas to replicate from the new master, and updates its own view of the topology.

Client rediscovery. Sentinel now answers queries for the master's address with the new node. Any client that talks to Sentinel — rather than hard-coding an IP — automatically follows the master to its new home.

Here is the shape of a minimal production topology:

Why You Need at Least Three Sentinels

It is tempting to run one or two Sentinels and move on. Don't. Failover authorization depends on a majority of the Sentinel set, so two Sentinels give you no fault tolerance at the decision layer — lose one and the survivor can never reach a majority to promote anything.

Three Sentinels is the practical minimum, and an odd number keeps voting decisive. For real resilience, place them in independent failure domains — separate hosts, racks, or availability zones — so that a single machine, network segment, or zone outage can never take out the majority at once. A Sentinel cluster that all runs on the same box protects you from a Redis crash but not from the thing that crashes the box.

Running Redis Sentinel

A Sentinel is really just Redis started in a special mode, so you have two equivalent ways to launch it. Using the dedicated executable:

redis-sentinel /path/to/sentinel.conf

Or by starting redis-server with the --sentinel flag:

redis-server /path/to/sentinel.conf --sentinel

Both require a configuration file, and both default to listening on port 26379. The configuration file is not optional: Sentinel rewrites it at runtime to persist the current state of the topology, so it can recover its bearings after a restart.

Redis Sentinel Configuration Explained

A basic sentinel.conf looks like this:

port 26379

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

Each directive earns its place:

• sentinel monitor mymaster 127.0.0.1 6379 2 tells Sentinel to watch a master group named mymaster at the given address, with a quorum of 2. The quorum is the number of Sentinels that must agree the master is unreachable before it can be declared objectively down. Name the group meaningfully — this is the identifier your clients will use to look the master up.
• down-after-milliseconds is how long a master can stop responding before a Sentinel marks it subjectively down. Set it too low and a brief network hiccup triggers a needless failover; too high and real outages linger.
• failover-timeout bounds how long a failover attempt may run before Sentinel considers it failed and is free to try again.
• parallel-syncs limits how many replicas resynchronize from the new master simultaneously after a promotion. Keeping it low avoids saturating the new master with full syncs while it is also trying to serve traffic.

If your master requires authentication, add sentinel auth-pass mymaster <password> so Sentinel can talk to it. You can monitor multiple, independent master groups from the same Sentinel set simply by adding another sentinel monitor block with a different name.

Common Sentinel Commands

Once Sentinel is running, you interact with it over the normal Redis protocol on its port. A few commands you will reach for constantly:

• SENTINEL MASTER mymaster — full status of the monitored master.
• SENTINEL MASTERS — every master this Sentinel watches.
• SENTINEL REPLICAS mymaster — the replicas Sentinel has discovered for that master.
• SENTINEL SENTINELS mymaster — the other Sentinels watching the same group.
• SENTINEL GET-MASTER-ADDR-BY-NAME mymaster — the current master address; this is essentially what clients call to find their way home after a failover.
• SENTINEL CKQUORUM mymaster — a health check that confirms enough Sentinels are reachable to both reach quorum and win a leader election.
• SENTINEL FAILOVER mymaster — force an immediate failover, useful for planned maintenance and for testing.

Running SENTINEL FAILOVER against a staging environment before you rely on Sentinel in production is one of the highest-value five-minute tests you can do.

Redis Sentinel vs Redis Cluster

Sentinel and Redis Cluster are often confused because both improve availability, but they solve different problems.

The short version: if a single node can hold your data and you simply need it to survive a node failure, Sentinel is the right, simpler tool. If you have outgrown one node and need to shard, you want Cluster. (We cover the trade-offs in depth in our dedicated Sentinel vs Cluster comparison.)

Connecting to Redis Sentinel from Java with Redisson

Here is the catch for application developers: Redis Sentinel speaks its own protocol, and neither Redis nor Sentinel works with Java out of the box. You need a client that understands Sentinel, discovers the topology, and — the part that matters most — quietly follows the master when a failover happens.

Redisson does exactly that. It connects to your Sentinels, discovers the master and replicas, keeps monitoring them, and reconnects to the promoted node automatically when the master changes. Your application code never contains failover logic.

Add the dependency (check Maven Central for the latest release):

<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson</artifactId>
    <version>4.6.1</version>
</dependency>

Then point Redisson at your Sentinels and name the master group — the same name from your sentinel monitor directive:

Config config = new Config();
config.useSentinelServers()
      .setMasterName("mymaster")
      .addSentinelAddress(
          "redis://127.0.0.1:26379",
          "redis://127.0.0.1:26380",
          "redis://127.0.0.1:26381")
      .setReadMode(ReadMode.SLAVE)
      .setCheckSentinelsList(true);

RedissonClient redisson = Redisson.create(config);

That is the whole integration. From here you use ordinary distributed objects, and Redisson transparently routes them to the right node — writes to the master, reads spread across replicas:

RMap<String, String> map = redisson.getMap("sessions");
map.put("user:42", "active");

RLock lock = redisson.getLock("report-lock");
lock.lock();
try {
    // critical section, safe across every JVM in your deployment
} finally {
    lock.unlock();
}

When Sentinel promotes a replica, Redisson detects the change and repoints these objects at the new master on its own. The RMap and RLock above keep working; your code does nothing.

A few configuration options are worth knowing for real deployments:

• Read scaling. setReadMode(ReadMode.SLAVE) sends reads to replicas; MASTER keeps them on the master; MASTER_SLAVE uses both. Pair it with a load balancer to spread read traffic.
• Security. Use rediss:// addresses for TLS, and setSentinelPassword(...) / setSentinelUsername(...) when your Sentinels authenticate separately from the data nodes (ACL support requires Redis 6.0+).
• Choice of API. The same configuration backs synchronous, asynchronous, Reactive, and RxJava3 clients — call redisson.reactive() or redisson.rxJava() when you need them.

Full details live in the Redisson configuration documentation, and if you are new to the client, start with how to connect to Redis in Java.

Production Considerations

Getting Sentinel working on localhost is easy. Keeping it healthy in production comes down to a few details that the quick-start tutorials skip.

NAT, Docker, and Kubernetes. Sentinel advertises the internal IP addresses of your Redis nodes. When your application runs outside that network — a common situation with Docker and Kubernetes — those addresses are unreachable, and naive clients fail after a failover. Redisson solves this with a NAT mapper: HostPortNatMapper and HostNatMapper translate the internal addresses Sentinel reports into the external ones your client can actually reach. This alone saves a great deal of debugging.

DNS-based topologies. If your nodes sit behind DNS names rather than fixed IPs, Redisson's DNS monitoring watches for address changes so the client keeps up. Make sure your JVM's DNS cache TTL is low enough for this to take effect.

Observability. Treat Sentinel as critical infrastructure and monitor it accordingly — track failover events, replication lag, and Sentinel reachability. Redisson exposes client-side metrics and tracing to help you see what the client is doing during a failover.

Cross-datacenter resilience. A single Sentinel group protects one region. For multi-region or disaster-recovery setups, look at running multiple Sentinel deployments with a replication relationship between them — see our walkthrough on creating regional replicas with multiple Redis Sentinels and the broader guide to Redis cross-datacenter replication.

Frequently Asked Questions

Is Redis Sentinel High Availability?

Yes. Sentinel provides high availability by monitoring your Redis master and replicas and automatically promoting a replica when the master fails. What it does not provide is horizontal scaling — it keeps one dataset available, it does not shard it across nodes.

What Is the Difference Between Redis Sentinel and Redis Cluster?

Sentinel adds automatic failover to a single master/replica group without sharding. Redis Cluster shards your data across multiple masters and adds failover on top. Choose Sentinel for HA on data that fits one node; choose Cluster when you need to scale beyond one node.

How Many Sentinels Do I Need?

At least three, and an odd number, spread across independent failure domains. Failover requires a majority of Sentinels, so three is the minimum that tolerates the loss of one while still being able to act.

Does Redis Sentinel Shard Data?

No. Every write still goes to a single master. If you need to distribute data across nodes, that is Redis Cluster's job, not Sentinel's.