How to Configure Redis Sentinel for High Availability and Automatic Failover on Ubuntu Server

ByAkensai

Learning how to configure Redis Sentinel for high availability and automatic failover on Ubuntu Server is one of the best decisions you can make for production environments. Redis Sentinel provides monitoring, automatic failover, and notification capabilities for your Redis setup. Without it, a single Redis master failure can bring down your entire application. This tutorial walks you through setting up a three-node Sentinel configuration on Ubuntu Server. You’ll install Redis, configure a master-replica pair, and then layer Sentinel on top to handle failover automatically. By the end, your Redis setup will detect failures and promote a replica to master without any manual intervention. This guide suits developers and sysadmins who are comfortable with the Linux command line and have basic Redis knowledge.

Prerequisites and Requirements for Redis Sentinel High Availability

Before you start, make sure you have the following in place.

What you need:

  • Three Ubuntu 22.04 servers (or VMs) with root or sudo access
  • Each server should have at least 1GB RAM and 1 CPU core
  • Static IP addresses assigned to all three servers
  • Open ports: 6379 (Redis) and 26379 (Sentinel) between all nodes
  • Basic familiarity with the Linux terminal and text editors like nano or vim

For this tutorial, the three servers will use these IPs:

  • Master: 192.168.1.10
  • Replica: 192.168.1.11
  • Sentinel node: 192.168.1.12

In practice, you’d run Sentinel on all three nodes. This guide uses a simplified layout to keep things clear. Estimated time to complete this setup is around 45 to 60 minutes.

You should also check the official Redis Sentinel documentation for deeper reference on configuration options.

How to Configure Redis Sentinel for High Availability: Step-by-Step Setup

You might also find this useful: How to Install and Configure Fail2ban on Ubuntu to Protect Against Brute-force Attacks

Follow these steps carefully on each server unless a step specifies a particular node.

Step 1: Install Redis on All Three Servers

Run these commands on each server to install Redis from the official Ubuntu package repository.

sudo apt update
sudo apt install redis-server -y

After installation, check that Redis is running:

sudo systemctl status redis-server

Step 2: Configure the Redis Master Node

On the master server (192.168.1.10), open the Redis config file:

sudo nano /etc/redis/redis.conf

Find and update these settings:

bind 192.168.1.10
protected-mode no
requirepass yourStrongPassword
masterauth yourStrongPassword

Save the file and restart Redis:

sudo systemctl restart redis-server

Step 3: Configure the Replica Node

On the replica server (192.168.1.11), open the same config file and set the following:

bind 192.168.1.11
protected-mode no
requirepass yourStrongPassword
masterauth yourStrongPassword
replicaof 192.168.1.10 6379

The replicaof directive tells this node to follow the master. Restart Redis on the replica:

sudo systemctl restart redis-server

Step 4: Verify Replication Is Working

On the master, run this command to confirm the replica has connected:

redis-cli -h 192.168.1.10 -a yourStrongPassword info replication

You should see output showing role:master and one connected replica. If the replica count shows zero, double-check your firewall rules and the replicaof setting.

Step 5: Configure Redis Sentinel on All Three Nodes

Each server needs a Sentinel configuration file. Create one on each node:

sudo nano /etc/redis/sentinel.conf

Add this configuration to each file, adjusting the bind address per server:

bind 192.168.1.10
port 26379
sentinel monitor mymaster 192.168.1.10 6379 2
sentinel auth-pass mymaster yourStrongPassword
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
sentinel parallel-syncs mymaster 1
logfile /var/log/redis/sentinel.log
daemonize yes

The sentinel monitor line tells Sentinel to watch the master. The number 2 at the end is the quorum. At least two Sentinels must agree before triggering a failover.

Step 6: Start Redis Sentinel on All Three Nodes

Run this command on each server to start Sentinel:

sudo redis-sentinel /etc/redis/sentinel.conf

To check that Sentinel is running correctly:

redis-cli -p 26379 info sentinel

You should see the master address and the number of Sentinels detected. All three should appear after a few seconds.

Step 7: Create a Systemd Service for Sentinel

You want Sentinel to start automatically on reboot. Create a service file:

sudo nano /etc/systemd/system/redis-sentinel.service

Paste this 

[Unit]
Description=Redis Sentinel
After=network.target

[Service]
ExecStart=/usr/bin/redis-sentinel /etc/redis/sentinel.conf
Restart=always

[Install]
WantedBy=multi-user.target

Enable and start the service:

sudo systemctl daemon-reload
sudo systemctl enable redis-sentinel
sudo systemctl start redis-sentinel

Step 8: Test Automatic Failover

Now simulate a master failure. On the master server, stop Redis:

sudo systemctl stop redis-server

Wait about 10 to 15 seconds, then check which node Sentinel has promoted:

redis-cli -p 26379 sentinel get-master-addr-by-name mymaster

The output should now show the replica’s IP address as the new master. That confirms automatic failover is working correctly. For more on Ubuntu server management, the Ubuntu Server documentation is a great reference.

Troubleshooting Common Redis Sentinel Configuration Issues

Even with careful setup, things can go wrong. Here are the most common problems and how to fix them.

Sentinel can’t reach the master: Check that port 26379 is open between all nodes. Use sudo ufw allow 26379 on each server if you have UFW enabled. Also verify port 6379 is open.

Quorum not reached during failover: This usually means one or more Sentinels can’t communicate. Confirm all three Sentinel processes are running and that the bind address in each sentinel.conf matches the server’s actual IP.

Authentication errors in logs: Make sure requirepass and masterauth match exactly across all nodes. A single typo will break replication and Sentinel auth.

Sentinel log shows wrong master IP: After a failover test, the old master’s config gets rewritten automatically. If you restart the old master, it should rejoin as a replica. If it doesn’t, manually set replicaof to the new master IP and restart.

Sentinel service fails on reboot: Check the systemd service file path. Make sure /etc/redis/sentinel.conf exists and is readable by the service user.

Conclusion: Keeping Redis Reliable with Sentinel

You now know how to configure Redis Sentinel for high availability and automatic failover on Ubuntu Server. You’ve set up a master, a replica, and a working Sentinel cluster that can detect failures and promote a new master without any manual steps. This setup is a solid foundation for production Redis deployments. From here, you might want to add more replica nodes for better read performance, or connect your application to Sentinel using a Sentinel-aware Redis client. Many Redis client libraries support Sentinel natively, so your app can always find the current master automatically. Keep your Sentinel logs monitored and test failover regularly to make sure everything stays healthy.

Similar Posts