Redis high availability comes from replication plus something that automates failover. Redis Sentinel gives you automatic failover for a single dataset; Redis Cluster gives you failover plus horizontal sharding across multiple primaries. Most teams need Sentinel. You need Cluster when one node can no longer hold your data or serve your throughput.
Replication alone is not high availability. A primary with replicas still needs a process that decides the primary is down, promotes a replica, and tells clients where to go. That decision layer is what actually distinguishes the architectures below.
Redis replication is the foundation
Every high availability architecture starts with the same primitive: one redis master accepting writes, and one or more replicas that replicate from it.
Redis replication is asynchronous. This asynchronous replication is what keeps the in-memory store fast. A write is acknowledged to the client before replicas confirm it, which keeps latency low and means a primary failure can lose the last few writes. That trade is deliberate and unavoidable — no high availability options make it disappear, so design for it rather than around it.
Replicas serve reads, but they do not remove the single point of failure. If the primary dies and nothing promotes a replica, the cluster is down for writes.
How Redis Sentinel works
Sentinel is a separate process that watches your monitored Redis instances and performs promotion automatically.
Run three sentinel instances minimum. Decisions need a majority, so three lets you tolerate one failure while still reaching agreement. Two cannot form a majority once one is gone.
When a failover occurs, the process runs like this:
- A Sentinel stops getting replies from the primary and marks it subjectively down
- It asks its peers; once enough agree, the primary is objectively down
- They elect a leader among themselves, which selects the best replica
- That replica is promoted to master, remaining replicas are reconfigured to follow it
- Clients discover the new primary by asking the monitor
That last step matters more than teams expect. Your redis client must be Sentinel-aware — it queries the monitor for the current primary address rather than holding a hard-coded IP address. Applications configured with a fixed IP keep writing to a demoted node and silently fail.
Deploy these processes on separate hosts from the redis server where you can. Colocating is common because the process is lightweight, but a host failure then removes both a Redis node and a vote at the same moment — exactly when you need the vote.
How Redis Cluster works
Redis Cluster will shard data across multiple redis instances, each with its own replicas. Keys map to 16,384 hash slots distributed across the shards.
Cluster provides high availability and fault tolerance the same way — replica promotion — but without a separate monitoring layer. The nodes agree among themselves. It also scales writes, which Sentinel cannot: with that approach, one primary handles every write regardless of how many replicas exist.
The cost is operational and application complexity. Multi-key operations must stay within one hash slot, some clients handle redirection poorly, and resharding a shard across multiple nodes is a real procedure rather than a config change.
Sentinel vs Cluster
| Redis Sentinel | Redis Cluster | |
|---|---|---|
| Data | One dataset, replicated | Sharded across multiple primaries |
| Write scaling | No — one primary | Yes |
| Automatic promotion | Yes | Yes |
| Extra processes | Sentinel nodes required | None |
| Client requirements | Sentinel-aware | Cluster-aware |
| Multi-key operations | Unrestricted | Same hash slot only |
| Good for | HA without sharding | HA plus horizontal scale |
The practical split between Redis Cluster and Redis Sentinel: choose Sentinel when your data fits comfortably on one node and you need availability without sharding. Choose the sharded option when it does not. Picking Cluster purely for redundancy adds complexity you will pay for during every incident.
Managed options — Redis Enterprise, Azure Cache for Redis, and the cloud providers' offerings — hide this choice behind their own architecture, typically spreading replicas across availability zones. Convenient, but you inherit their promotion semantics rather than choosing your own.
Why Does Redis Sentinel Split-Brain and Not Recover Automatically?
Split-brain in a Sentinel-managed Redis deployment happens when a network partition (or a cascading restart event) leaves two groups of nodes each believing they have quorum and should be — or already are — acting as primary. Unlike RabbitMQ's pause_minority behavior, which deliberately halts the minority partition to prevent divergence, Redis Sentinel's failover and recovery model depends on Sentinels reaching quorum agreement about which node is actually down — and that agreement process is where real production incidents have gotten stuck.
What causes it in practice. A real production Redis assessment identified split-brain and automated recovery failures in Redis Sentinel as a dedicated investigation workstream, arising specifically from Sentinel bootstrap reliability issues during cluster restart — meaning the problem wasn't a single dramatic network partition, but Sentinels failing to correctly re-establish quorum and agree on primary/replica roles when the cluster came back online after a restart or crash recovery event.
Why it doesn't self-heal. Sentinel's failover logic requires a configured quorum of Sentinel processes to agree that the primary is genuinely unreachable before promoting a replica. If Sentinels themselves restart in an inconsistent order, or if the underlying infrastructure event that caused the original problem also disrupted Sentinel-to-Sentinel communication, you can end up in a state where no single Sentinel group has clean quorum — and the automatic failover mechanism that's supposed to resolve exactly this kind of event doesn't trigger cleanly, requiring manual intervention.
What to check if you hit this:
- Confirm all Sentinel processes can reach each other and the monitored Redis nodes on the required ports — a partial network issue that resolved for data traffic but not Sentinel gossip traffic can leave Sentinel quorum broken even after your application-level connectivity looks fine
- Review your Sentinel
quorumconfiguration relative to your actual Sentinel process count — an undersized quorum requirement relative to your deployment topology increases the chance of exactly this kind of ambiguous state - Check Sentinel logs specifically (not just Redis server logs) for repeated, failed failover attempts or disagreement between Sentinels about the current primary — this is the direct signature of a quorum/bootstrap problem rather than a simple node failure
- If you're running Sentinel bootstrap as part of an automated deployment (container restart, orchestrator-managed redeploy), validate that your bootstrap sequencing doesn't race — Sentinels coming online before they can reach each other or the monitored nodes is a common trigger for exactly this failure mode
The practical mitigation: if you're seeing recurring Sentinel split-brain specifically correlated with restarts (rather than genuine network partitions), the fix usually isn't a Sentinel configuration change alone — it's fixing the bootstrap/restart sequencing so Sentinels have reliable connectivity to each other and to the Redis nodes before failover logic engages. Redis Cluster mode (rather than Sentinel-managed standalone/primary-replica) handles some of these coordination problems differently and is worth evaluating if Sentinel bootstrap reliability is a recurring operational pain point for your deployment specifically.
How to configure Redis for high availability
A workable baseline for a Sentinel setup:
# redis.conf on each replica
replicaof <primary-ip> 6379
min-replicas-to-write 1
min-replicas-max-lag 10# sentinel.conf — three sentinel processes
sentinel monitor mymaster <primary-ip> 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000The trailing 2 is the quorum: how many must agree before promotion starts. With three sentinel instances, two is correct.
You configure Sentinel separately, and min-replicas-to-write is the setting most teams skip. It makes the primary refuse writes when fewer than the configured number of replicas are connected, which converts silent data loss into a visible error. Tune down-after-milliseconds to your network — too aggressive and normal latency triggers spurious promotions.
Why highly available Redis still goes down
Correct configuration is not sufficient. Three failure modes we have worked on recently, none of which a config review catches.
Memory exhaustion during background saves. Redis forks to write a snapshot, and the fork uses copy-on-write. If your workload writes heavily during the save, the parent and child diverge and memory usage climbs toward double the dataset. We investigated a customer seeing repeated crashes at around 60 percent memory utilization — well under any threshold they were alerting on — caused precisely by fork behavior during backups. The fix was kernel-level tuning of memory overcommit behavior, not a Redis setting.
Plan capacity so peak usage plus fork overhead fits in RAM. Fifty percent steady-state is a reasonable ceiling for a write-heavy instance that snapshots.
Split-brain during bootstrap. In the same environment, DNS lag during startup caused split-brain: nodes resolving stale addresses formed inconsistent views of who the primary was. This is a bootstrap-order problem, not a steady-state one, and it appears only when the whole cluster restarts together — which is exactly what happens in Kubernetes during a node drain or rolling update.
Scripted, DNS-dependent bootstrapping is fragile enough that we are building a plugin to automate Sentinel bootstrapping with Raft-based consensus instead, removing the external dependency altogether.
Replica stalls. A replica that falls far behind and needs a full resynchronization forces the primary into another fork — often at the worst moment. Monitor replica lag as a first-class metric, not an afterthought.
Seeing Redis crashes you cannot explain from the config? These failures usually sit below Redis — in kernel memory behavior, DNS, or orchestration. AceMQ runs structured Redis assessments that find them. Talk to an AceMQ engineer.
Redis on Kubernetes
Kubernetes changes the failure model. Pods move, IP addresses change, and the whole distributed system can restart at once during a rolling update.
Three rules that prevent most incidents:
- Use StatefulSets with stable network identities, so a restarted Redis instance keeps a predictable name rather than a new address
- Spread replicas across nodes and availability zones with anti-affinity — replicas on the same physical node provide no protection
- Set PodDisruptionBudgets so a drain cannot evict the primary and a majority of Sentinel nodes together
Redis and Sentinel both need this treatment. Protecting the data nodes while leaving the monitor pods freely evictable removes the majority that makes promotion work.
Best practices
- Three sentinel instances, on separate failure domains from the redis server hosts
- Multiple replicas — at least two of every primary node, so one failure still leaves a promotion candidate
- Sentinel-aware or Cluster-aware clients — never hard-code a primary IP address
min-replicas-to-writeso the primary fails loudly rather than losing writes quietly- Capacity for fork overhead, not just the working set
- Alert on replica lag, memory fragmentation, and monitor health — not just on whether the process is up
- Test it deliberately. An untested promotion path is a hypothesis, not a guarantee
If you want the same treatment for your messaging layer, our RabbitMQ troubleshooting guide covers the equivalent failure modes there. For hands-on help with a production estate, see Redis support and incident response.
On virtualized infrastructure, placement matters as much as topology — see Redis anti-affinity on VMware.
Choosing between Sentinel and Cluster: the decision rule and the common wrong choice
The decision comes down to one question: does the dataset, and the write rate against it, fit on one node? Yes means Sentinel, no means Cluster.
Sentinel is failover for a single replicated dataset. One primary holds every key, replicas copy it, and the sentinels watch, agree by quorum that the primary is gone, promote a replica, and answer clients asking for the new primary. You keep standalone Redis semantics: MULTI/EXEC and Lua across any keys. The only client change is a sentinel lookup on connect and on error.
Cluster is sharding with failover built in. The keyspace is split into 16384 hash slots across several primaries, each with its own replicas. A client that asks the wrong node gets a MOVED redirect (permanent) or an ASK redirect (mid migration) and must follow it, so it needs a cluster-aware library that keeps a current slot map. Multi-key commands, transactions and Lua need every key in the same slot, so key names carry hash tags such as {user:42}:profile.
Pick Sentinel when the dataset fits on one node with headroom, one primary can absorb the write rate, you depend on transactions or Lua across arbitrary keys, or your clients are simple. Pick Cluster when the dataset or write throughput is beyond one node and horizontal growth is planned.
The wrong choice we see most is Cluster for a 4 GB dataset because it sounds more available. It is not: Cluster failover is the same replica promotion, with a stricter condition (a majority of primaries reachable) and twice the footprint. You pay client complexity and key design for sharding you do not need. We have moved more than one team back to Sentinel without losing availability.
What actually happens during a Redis failover, and where writes get lost
Under Sentinel the sequence is fixed. A sentinel that gets no valid reply within down-after-milliseconds marks the primary SDOWN (subjectively down). It asks the other sentinels, and once quorum agree the primary is ODOWN. The sentinels elect a leader by epoch-numbered vote; the leader needs a majority of all sentinels, not just quorum, which is why two sentinels cannot fail over with one down. The leader picks the replica with the lowest replica-priority, then the highest replication offset, sends it REPLICAOF NO ONE, points the other replicas at it and publishes +switch-master. Clients ask any sentinel for the current primary and reconnect. failover-timeout caps each step and the retry interval.
Under Cluster the primaries are the jury. A node silent for cluster-node-timeout is flagged PFAIL; failure reports spread by gossip, and once a majority of primaries agree it becomes FAIL. Each replica of the dead primary waits a delay ordered by replication offset, so the one with the most data asks for votes first. It requests votes with a new epoch, needs a majority of primaries, and each primary votes once per epoch. The winner claims the slots, bumps its config epoch and broadcasts. Clients learn through MOVED redirects and refresh their slot map.
In both modes, replication is asynchronous: the primary acknowledges to the client before the replica has the write. Everything in that window when the primary dies is gone, because the promoted replica's offset becomes the truth. The window is normally milliseconds; with a lagging replica it is seconds.
min-replicas-to-write and min-replicas-max-lag bound the window. With 1 and 10, a primary refuses writes unless at least one replica is connected and reported in within ten seconds. It does not make replication synchronous; for a single write that must survive, use WAIT.
The same settings are the Sentinel answer to split-brain. An old primary cut off from the sentinels but still reachable by some clients keeps accepting writes until it is reconfigured, all discarded on rejoin. Once its replicas follow the new primary it fails the min-replicas check and rejects writes. Cluster is more decisive: a primary on the minority side of a partition stops serving after cluster-node-timeout and returns CLUSTERDOWN.
Set down-after-milliseconds and cluster-node-timeout high enough that a GC pause or VM stall does not trigger a needless failover (see VMware anti-affinity). Set client timeouts longer than measured failover time, retry with backoff on connection errors and on READONLY, and confirm the library re-queries sentinels or the slot map rather than caching an address. Then rehearse both a killed process and a firewall partition, because most failover surprises only show up on a partition. Minimum sensible counts: three sentinels on three failure domains; for Cluster, three primaries with one replica each. What we see clients get wrong, in order: two sentinels, sentinels on the same host as the Redis they watch, a hard-coded primary address in the application, and client timeouts shorter than the failover. Our Redis consulting work usually starts by fixing one of those.
This is step one of seven in the Redis reliability guide, which takes the problems in the order they arrive on a production estate.
FAQ
What is Redis high availability?
An architecture that keeps Redis serving through node failure, combining replication with automatic failover. Replication alone is not enough — something must detect failure, promote a replica, and redirect clients.
What is the difference between Redis Sentinel and Redis Cluster?
Sentinel adds automatic promotion to a single replicated dataset. Cluster shards data across multiple primaries and handles failure internally. One gives availability; the other gives availability plus write scaling.
How many sentinel instance processes do I need?
Three minimum. Failover requires quorum agreement, and three tolerates one monitor failure while still reaching a majority. Two cannot.
Does Redis lose data during a failover?
It can. Redis replication is asynchronous, so writes acknowledged by the primary but not yet replicated are lost when it fails. min-replicas-to-write limits exposure by refusing writes when too few replicas are connected.
How does the monitor decide a primary is down?
One process marks it subjectively down after no reply within down-after-milliseconds. When enough of them agree to meet the configured quorum, it becomes objectively down and failover starts.
Why does Redis crash when memory looks fine?
Usually the background save fork. Copy-on-write means memory can approach double the dataset during a snapshot under write load, so a node sitting at 60 percent utilization can still exhaust RAM mid-save. Size for peak plus fork overhead.
Can I run a highly available Redis on Kubernetes?
Yes, with StatefulSets, anti-affinity across nodes and availability zones, and PodDisruptionBudgets covering both Redis and Sentinel. The common failure is a rolling update evicting the primary and Sentinel quorum simultaneously.
How many nodes does Redis Cluster need for high availability?
Six: three primaries, each with one replica. Three primaries is the smallest set that can form a majority for failure detection and replica election while one of them is down, and a replica per primary is what makes failover possible at all. Spread the six across at least three failure domains, and make sure no primary shares a host or hypervisor with its own replica. Larger clusters follow the same rule: keep an odd number of primaries where you can, and never run a primary without a replica. AceMQ Redis support covers failover testing and topology review on a 15-minute P1 response, 24 hours a day.
