Redis Sentinel: Basics, Tutorial, and Tips for Success

What Is Redis Sentinel? 

Redis Sentinel is a distributed system that provides high availability (HA) for Redis deployments. Its primary purpose is to monitor Redis primary and replica instances (or master and slave instances), detect failures, and perform automated failover to ensure continuous operation. If the primary fails, the Sentinels automatically elect the most up-to-date replica and promote it to be the new primary. This allows clients to reconnect with minimal disruption, ensuring continuous operation.

Redis Sentinel addresses the shortcomings of basic Redis replication, where the absence of automatic failover means manual intervention is needed during failures. Sentinel eliminates this manual burden and helps prevent service disruptions by managing primary-replica relationships and maintaining updated configuration details.

A Typical Redis Sentinel Deployment (Source: Redis)

In this article:

• How Redis Sentinel Works
• Redis Sentinel vs. Redis Cluster
• Tutorial: Getting Started with Redis Sentinel
• Running Redis Sentinel: 5 Tips for Success

How Redis Sentinel Works 

Redis Sentinel can be deployed standalone or in a distributed topology, typically with 3-5 nodes recommended. The Sentinel deployment is responsible for monitoring the health of Redis servers, coordinating failover, and maintaining configuration information.

The primary process flow involves the following steps:

• Monitoring: Sentinels continuously check the health of the Redis primary and replica instances. They ping these nodes at regular intervals and assess their responses. If a node fails to respond or shows signs of failure, such as replication issues or prolonged downtime, it is marked as subjectively down. Once a quorum of Sentinels agrees on the failure, the node is considered objectively down.
• Failover Procedure: When a primary node is down, Sentinels initiate an automatic failover process. They elect a new primary from the available replicas based on preconfigured criteria. Once a new primary is selected, Sentinels update the other replicas to follow the new primary.
• Client Redirection: Redis clients discover the primary using Sentinel’s APIs. When failover occurs, Sentinel-aware clients usually query Sentinels to discover the updated primary address automatically.
• Continuous Monitoring & Reconfiguration: After failover, Sentinel continuously monitors the previously failed primary. Once it recovers and is healthy, Sentinel may reintroduce it into the HA topology as a replica or, in some cases, promote it back to primary, depending on the system configuration and requirements.

Redis Sentinel vs. Redis Cluster 

While both Redis Sentinel and Redis Cluster aim to improve Redis availability and scalability, they serve different purposes and operate in distinct ways.

Redis Sentinel focuses on high availability through monitoring and automatic failover. It ensures that a Redis primary instance is highly available by promoting one of the replicas to be the new primary if the current one fails. Sentinel does not provide any inherent data sharding, but it does provide a certain level of horizontal scalability for read operations. It operates by managing a Redis primary instance with multiple replicas that can be promoted to the primary role when needed.

Redis Cluster is designed for horizontal scalability for both read and write operations. It allows Redis to partition data across multiple nodes, enabling the distribution of both data and requests. A Redis Cluster consists of multiple primary instances, each responsible for a subset of the data, and replicas of these primary instances for fault tolerance. Redis Cluster can handle automatic failover for each shard, ensuring that data remains accessible even when a primary node fails.

Tutorial: Getting Started with Redis Sentinel

To get started with Redis Sentinel, you’ll need to deploy more than one Redis instance and configure them with different roles (i.e., Sentinel, primary, and replica). Below are the key steps to deploy and configure Redis Sentinel for high availability. These instructions are adapted from the Redis documentation.

1. Install Redis

To use Redis Sentinel, you first need to install Redis. A Sentinel instance is essentially a Redis server running in this special mode.

You can download the latest version of Redis from the official Redis website or install it using package managers like apt, yum, or brew on Linux and macOS systems.

For example, on Ubuntu:

$> sudo apt update
$> sudo apt install redis-server

On Ubuntu, you may need to install Sentinel separately using the following command:

$> sudo apt install redis-sentinel

2. Configure Redis Primary and Replica Servers

Before setting up Redis Sentinel, you need a basic Redis setup with at least one primary and one replica. For example, you can configure a Redis primary at 127.0.0.1:6379 and a replica at 127.0.0.1:6380 by setting the replica’s configuration file as follows:

# In the replica's redis.conf, update the following settings
port 6380
replicaof 127.0.0.1 6379

Make sure to start both Redis servers, ensuring that they are running and replicating correctly. We can use following command:

$> ps aux | grep redis

3. Configure Redis Sentinel

Create a Sentinel configuration file sentinel.conf for each Sentinel instance. A typical minimal Sentinel configuration file looks like this:

# sentinel.conf
sentinel monitor my-primary 127.0.0.1 6379 2
sentinel down-after-milliseconds my-primary 60000
sentinel failover-timeout my-primary 180000
sentinel parallel-syncs my-primary 1

Here, my-primary refers to the name of the Redis primary, 127.0.0.1 is the primary instance’s IP address, and 6379 is its port. The quorum is set to 2, meaning at least two Sentinels need to agree that the primary is down before failover can occur.

4. Start Redis Sentinel

Once the configuration file is ready, you can start Redis Sentinel by running the following command:

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

Or if it is a service, you can check for its existence using the following command:

$> systemctl list-units --type=service | grep redis-sentinel

In our case, the service is named redis-sentinel.service. We can restart it using the following command:

$> systemctl restart redis-sentinel.service

We can check its status using the following command:

$> systemctl status redis-sentinel.service

This will start a Redis Sentinel instance that monitors the primary at 127.0.0.1:6379. You should start at least three Sentinel instances on different machines or virtual machines to ensure high availability and fault tolerance.

5. Test Redis Sentinel Failover

After setting up Redis Sentinel, you can test its failover capabilities by shutting down the primary Redis server:

$> redis-cli -h 127.0.0.1 -p 6379 SHUTDOWN

After shutting down the primary, Sentinel should detect the failure and automatically promote a replica to the primary role. You can check the failover status by querying Sentinel:

$> redis-cli -p 26379 SENTINEL get-master-addr-by-name my-primary
#=> 1) "127.0.0.1"
#=> 2) "6380"

The command will return the address and port of the new primary. Your application can query Sentinel to get the updated primary address, ensuring minimal downtime. Note that 26379 is the default port for Sentinel. When running multiple Sentinel instances, make sure that they have different ports locally, or ideally make sure they are on different server machines for production-grade deployment. The same guideline applies to Redis primary and replica instances too.

6. Monitor and Maintain Sentinel Setup

Once your Redis Sentinel setup is running, it’s important to monitor the health of your nodes and ensure that your setup is functioning correctly. You can use Redis Sentinel’s built-in commands like SENTINEL get-master-addr-by-name, SENTINEL masters, and SENTINEL replicas to check the status of your Redis nodes and Sentinels.

Make sure that your Redis clients are configured to use Sentinel for automatic primary discovery, allowing your application to quickly adjust to failover scenarios without manual intervention.

Running Redis Sentinel: 5 Tips for Success 

Here are some of the ways that organizations can ensure the effective use of Redis Sentinel.

1. Ensure Proper Sentinel Deployment with Redundancy

When deploying Redis Sentinel, it’s recommended to have a minimum of three Sentinel instances. This ensures that there is enough redundancy and fault tolerance for Sentinels to reach a consensus on the state of the Redis primary.

By placing these Sentinels on different physical or virtual machines, you reduce the likelihood of all Sentinels being affected by the same failure. If a failure occurs on one machine, the other Sentinels can continue to operate, ensuring the entire deployment remains available and consistent. Additionally, the distributed nature of Sentinels helps eliminate single points of failure, which is crucial for high availability in production environments.

2. Configure Timeouts and Failover Parameters Appropriately

Configuring timeouts and failover parameters is critical to ensure smooth failover operations. The down-after-milliseconds parameter determines how long a primary node can be unresponsive before Sentinel marks it as down. Setting this to a reasonable value (e.g., 30 seconds) prevents unnecessary failover attempts while ensuring that Redis remains available during short network disruptions.

Besides, there are many other useful parameters that can be found in sentinel.conf you may configure to fit specific application or business requirements.

3. Use Sentinel-Aware Clients for Failover Awareness

To fully benefit from Redis Sentinel, use Sentinel-aware clients that can automatically adjust connections to the new primary instance during failover events. Sentinel-aware clients query the Sentinel instances to get the updated primary address, ensuring that your application always communicates with the correct Redis primary.

For example, Redis clients like redis-py offer built-in support for Sentinel, allowing them to discover the current primary and replica nodes automatically. Once connected, clients talk to Redis instances directly to minimize latency. However, clients still query Sentinel periodically for the primary/replica information, as Sentinel is not a proxy for normal data operations.

4. Monitor Sentinel Logs and Events to Ensure System Health

It is essential to monitor the logs and events generated by Redis Sentinel to ensure that it is functioning properly. Sentinel generates various events during its operation, such as +sdown, +odown, and +failover-detected, which provide insights into the health and status of Redis nodes and the failover process.

By subscribing to these events or periodically checking Sentinel logs, administrators can stay informed about the system’s health and take proactive actions if any anomalies arise. For instance, if a Sentinel fails to reach a quorum during failover, monitoring these events will alert you to potential issues before they escalate into more significant problems, ensuring that Redis high availability is not compromised.

5. Test Failover in a Controlled Environment

Testing the failover process regularly is critical to ensure that your Redis Sentinel setup is functioning correctly. Simulating primary failures in a controlled environment allows you to observe how Redis Sentinel responds to failures and whether the failover process works as expected. This includes checking if replicas are correctly promoted to primary instances and whether clients can continue operations without disruptions.

Testing should be part of a regular maintenance cycle and ideally performed in a staging environment before making any changes in production. By running periodic failover tests, you ensure that your Redis infrastructure remains reliable and that failover procedures are well-practiced, minimizing the risk of unexpected downtime during real-world incidents.

Dragonfly: The Next-Generation In-Memory Data Store

Dragonfly is a modern, source-available, multi-threaded, Redis-compatible in-memory data store that stands out by delivering unmatched performance and efficiency. Designed from the ground up to disrupt existing legacy technologies, Dragonfly redefines what an in-memory data store can achieve.

Since Dragonfly is fully compatible with the Redis protocol, Sentinel can also manage Dragonfly in a high availability deployment. See more details in our blog post Keeping Dragonfly Always-On: High Availability Options Explained.

Key Advancements of Dragonfly

• Multi-Threaded Architecture: Efficiently leverages modern multi-core processors to maximize throughput and minimize latency.
• Unmatched Performance: Achieves 25x better performance than Redis, ensuring your applications run with extremely high throughput and consistent latency.
• Cost Efficiency: Reduces hardware and operational costs without sacrificing performance, making it an ideal choice for budget-conscious enterprises.
• Redis API Compatibility: Offers seamless integration with existing applications and frameworks running on Redis while overcoming its limitations.
• Innovative Design: Built to scale vertically and horizontally, providing a robust solution for rapidly growing data needs.

Dragonfly Cloud is a fully managed service from the creators of Dragonfly, handling all operations and delivering effortless scaling so you can focus on what matters without worrying about in-memory data infrastructure anymore.