How to Prevent Redis Single‑Point Failures with Sentinel and Master‑Slave Replication

1. Redis Overview

Redis is a high‑performance in‑memory key‑value store that supports persistence, high availability, multiple data structures, and clustering, making it a popular non‑relational database.

Session cache : Persistent storage enables long‑lived sessions, improving user experience in scenarios like shopping carts.

Full‑page cache : Plugins such as wp‑redis for WordPress accelerate page loads.

Queue : List and set operations allow Redis to act as a reliable message queue, e.g., limiting purchase frequency during promotions.

Ranking : Atomic increment/decrement operations are ideal for ranking items such as novels.

Publish/Subscribe : Enables real‑time features like chat systems.

2. Risks of Single‑Node Deployments

Despite Redis’s versatility, many organizations still use a single‑node setup, which introduces a single point of failure. In 2015 a production incident occurred where a Redis instance controlling purchase limits crashed, allowing users to buy discounted items repeatedly and causing unrecoverable business loss.

3. Backup and Disaster Recovery in Non‑Distributed Scenarios

Common Master‑Slave Replication

Two typical architectures are widely used:

One master with two slaves. Writes go to the master; reads are distributed across the slaves, reducing read load on the master.

Same master‑slave topology but the master and one slave share a virtual IP (VIP) managed by keepalived. Clients connect via the VIP, avoiding IP changes during failover.

Advantages

Provides backup of master data; if the master fails, a slave can be promoted.

Enables read scaling by offloading reads to slaves.

Disadvantages

Both schemes require manual intervention for failover. In Scheme 1, when the master fails the client loses write capability and slaves cannot replicate. In Scheme 2, after the master fails the client can connect to a slave, but that slave becomes a new single point of failure.

Manual failover steps (common to both schemes):

On the chosen slave, execute slaveof no one to promote it to master.

Configure the promoted slave as writable (slaves are read‑only by default).

Notify client applications of the new master address.

Reconfigure the remaining slave to replicate from the new master.

4. Introduction to Redis Sentinel

Redis Sentinel offers a high‑availability solution that automates monitoring, notification, and failover without human intervention. Multiple Sentinel processes work together to detect master failures and coordinate recovery.

5. Sentinel Functions

Monitoring : Continuously checks the health of masters and slaves.

Notification : Sends alerts via API when a Redis instance fails.

Automatic failover : Promotes a slave to master and reconfigures other slaves when the master is down.

Configuration provider : Clients query Sentinel to obtain the current master address, automatically receiving updates after failover.

6. Sentinel Architecture

7. Sentinel Failover Process

Sentinel instances elect a leader.

The leader selects a suitable slave to become the new master based on criteria such as disconnect time, slave priority, replication offset, and Run ID.

The leader runs slaveof no one on the chosen slave to promote it.

The leader instructs remaining slaves to replicate from the new master.

The former master is demoted to slave; when it recovers, it syncs from the new master.

All steps are performed automatically, eliminating manual intervention.

Conclusion

Using Sentinel achieves fully automatic Redis high availability; when the master fails, failover occurs without impacting business. Deploy an odd number of Sentinel nodes, with a minimum of three, to ensure reliable elections.