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.
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 utilisation — well under any threshold they were alerting on — caused precisely by fork behaviour during backups. The fix was kernel-level tuning of memory overcommit behaviour, 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 resynchronisation 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 behaviour, 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 consulting and support.
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 utilisation 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.
