Building a High‑Availability Redis System with Sentinel and VIP

When a single Redis instance fails, the entire system becomes unavailable; therefore, a high‑availability solution is required.

Backup with multiple Redis replicas (typically three) ensures that if one node goes down, others can continue serving.

Redis Sentinel provides automatic failover: when the master is down, Sentinel promotes a replica to master and reconfigures the remaining replicas.

Practical setup

1. Environment – Use three servers, each running a Redis server on port 8000 and a Sentinel on port 6800 . Example addresses:

192.168.56.101:8000 (master)

192.168.56.102:8000 (slave)

192.168.56.103:8000 (slave)

Sentinel ports: 192.168.56.101:6800, 192.168.56.102:6800, 192.168.56.103:6800.

2. Install Redis

wget http://download.redis.io/releases/redis-3.2.8.tar.gz
 tar zxvf redis-3.2.8.tar.gz
 cd redis-3.2.8
 make
 cd src
 sudo cp redis-cli redis-server redis-sentinel /usr/sbin/

Copy the example configuration files and edit them.

3. Configure master redis‑server

port 8000            # change default port for safety
 daemonize yes
 bind 0.0.0.0
 pidfile /var/run/redis-8000.pid
 logfile /var/log/redis/redis-8000.log

4. Configure slave redis‑server

port 8000
 daemonize yes
 bind 0.0.0.0
 pidfile /var/run/redis-8000.pid
 logfile /var/log/redis/redis-8000.log
 slaveof 192.168.56.101 8000   # additional line for replication

Start the servers:

sudo redis-server /etc/redis.conf

Verify replication with redis-cli -h 192.168.56.101 -p 8000 info replication . If no slave info appears, open the firewall ports:

# edit firewall rules
 sudo vim /etc/sysconfig/iptables   # add 8000 and 6800 ports
 sudo service iptables restart

5. Configure Sentinel

daemonize yes
 port 6800
 logfile /var/log/redis/sentinel.log
 pidfile /var/run/sentinel.pid
 sentinel monitor master8000 192.168.56.101 8000 2
 sentinel down-after-milliseconds master8000 5000
 sentinel failover-timeout master8000 15000

Start Sentinel:

redis-sentinel /etc/sentinel.conf

After all three Sentinel instances run, you can query any of them to see the current master.

6. Testing failover

Shut down the master:

redis-cli -h 192.168.56.101 -p 8000 shutdown

Sentinel will promote a slave to master; you can observe the change via Sentinel’s monitoring UI.

7. Client connection handling

Clients can query Sentinel with SENTINEL get-master-addr-by-name <master name> to obtain the current master’s IP and port before each operation, though this adds an extra request.

8. VIP solution

Assign a virtual IP (e.g., 192.168.56.250) to the current master so clients always connect to the VIP. When failover occurs, move the VIP to the new master.

Use Sentinel’s client-reconfig-script to automate VIP migration. Example script ( /opt/notify_master6800.sh ):

#!/bin/bash
MASTER_IP=$6   # new master IP
LOCAL_IP='192.168.56.101'   # change per server
VIP='192.168.56.250'
NETMASK='24'
INTERFACE='eth1'
if [ ${MASTER_IP} = ${LOCAL_IP} ]; then
  /sbin/ip addr add ${VIP}/${NETMASK} dev ${INTERFACE}
  /sbin/arping -q -c 3 -A ${VIP} -I ${INTERFACE}
  exit 0
else
  /sbin/ip addr del ${VIP}/${NETMASK} dev ${INTERFACE}
  exit 0
fi
exit 1   # Sentinel will retry if non‑zero

Add the line to each sentinel.conf :

sentinel client-reconfig-script master8000 /opt/notify_master6800.sh

Manually bind the VIP to the current master if needed:

/sbin/ip addr add 192.168.56.250/24 dev eth1
/sbin/arping -q -c 3 -A 192.168.56.250 -I eth1

After shutting down the master, the VIP migrates to the new master, and clients can continue using the same IP.

Conclusion

The described setup—Redis master‑slave replication, Sentinel for automatic failover, and VIP migration—provides high availability for a single Redis instance, suitable for small‑scale applications; larger workloads should consider Redis Cluster or other scaling solutions.