We often encounter a situation: the Redis master fails, and the application loses cache or sessions for several minutes. Manual switching to a replica takes 5–15 minutes of downtime, lost transactions, and stress. Without automation, you have to manually log in to the server, run SLAVEOF NO ONE, and reconfigure client applications. This is time-consuming and error-prone, especially during nights or weekends. The solution is Redis Sentinel: a system that automatically detects master failure, promotes a new master, and notifies clients. Sentinel is 10 times faster than manual switching—failover takes 10-20 seconds. Client libraries like phpredis and predis support automatic redirection to the new master without code changes. With proper configuration, the application loses at most 20 seconds of connection before resuming with the new replica.
Why three Sentinels?
Sentinel uses a voting algorithm: when contact with the master is lost, each Sentinel proposes promoting a replica. A decision is made only with a quorum—a majority of votes. With two Sentinels, split-brain is possible (each considers its candidate master). Three servers with quorum = 2 guarantee a correct failover.
How to configure Redis Master and Replica in 6 steps
- Install Redis on all three servers (same version, e.g., 7.2).
- Configure the master—set passwords, memory limit, enable AOF.
- Configure replicas—add parameter
replicaof <master-ip> 6379. - Configure Sentinel—create
sentinel.confwith monitor, password, and timeout settings. - Start Sentinel on all servers with
redis-sentinel /etc/redis/sentinel.conf. - Check the status—run
SENTINEL mastersto confirm the master is detected.
Example master config (/etc/redis/redis.conf):
bind 0.0.0.0
port 6379
requirepass RedisPassword123
masterauth RedisPassword123
maxmemory 4gb
maxmemory-policy volatile-lru
appendonly yes
appendfsync everysec
protected-mode noReplica config is the same but add replicaof <master-ip> 6379 and replica-read-only yes.
Example Sentinel config (/etc/redis/sentinel.conf on each server, only sentinel announce-ip changes):
port 26379
daemonize yes
logfile /var/log/redis/sentinel.log
sentinel monitor mymaster <master-ip> 6379 2
sentinel auth-pass mymaster RedisPassword123
sentinel down-after-milliseconds mymaster 5000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 60000
sentinel notification-script mymaster /opt/redis/notify.sh
sentinel announce-ip <server-ip>
sentinel announce-port 26379How to test failover without risk?
We recommend simulating before production:
- Stop the master:
systemctl stop redis. - Observe Sentinel logs—failover should begin within 5–15 seconds.
- Check the new master:
SENTINEL master mymaster—theipfield will change. - Start the old master again:
systemctl start redis—it will automatically become a replica of the new master.
Common testing mistakes:
- Passwords not verified—failover may fail due to auth-pass.
- Too large down-after-milliseconds—delay up to 30 seconds.
- Missing notification-script—you won't know about master change.
What to do if Sentinel cannot reach quorum?
Check network connectivity between servers (ports 26379 must be open). Ensure the config has the correct `sentinel announce-ip`. If servers are behind NAT, explicit external IPs may be required. For debugging, use `SENTINEL ckquorum mymaster`.Comparison: Sentinel vs. Redis Cluster
| Criterion | Redis Sentinel | Redis Cluster |
|---|---|---|
| Data volume | Fits in one server's RAM | Exceeds one server's RAM |
| Fault tolerance | Automatic failover | Automatic failover and resharding |
| Write location | Only master | Any node (sharding) |
| Setup complexity | Low | High |
| Multi-key operations | Full support | Limited to same slot |
For 90% of projects with data volumes up to 64 GB, Sentinel is the optimal choice.
Comparison of downtime
| Method | Average downtime |
|---|---|
| Manual switch | 10 minutes |
| Redis Sentinel | 15 seconds |
By automating, you save dozens of hours per year and eliminate human error.
What is included in the turnkey setup
We provide:
- Configuration of Master+Replica+Sentinel on 3 servers
- Quorum and failover mechanism verification
- Notification setup (Telegram, email) on master change
- Failover test script
- Client integration (Laravel, Symfony, plain PHP)
- Operations documentation
We have implemented Sentinel in over 50 projects—experience shows that 80% of incidents resolve automatically without engineer intervention. According to official Redis Sentinel documentation, this configuration ensures 99.9% availability when properly configured.
Timeline and guarantees
Standard setup of Sentinel with three servers, failover testing, and integration takes 1 to 2 business days. Cost is calculated individually. The investment pays off through reduced downtime. We offer a 30-day guarantee on the correct operation of the fault tolerance scheme.
Order Redis Sentinel setup—and forget about manual switching. Get an engineer consultation to estimate the cost for your project.
Note: In the configurations above, use your own password and IP addresses. Do not forget to open ports 6379 (Redis) and 26379 (Sentinel) in the firewall.