In this lesson, you will learn how to use Redis Sentinel to automate the failover process, ensuring your application remains resilient even when your primary database instance crashes.
The Problem: The Single Point of Failure
When using a master-replica setup, your database performance scales through read offloading. However, if your primary (master) node goes down, your write operations fail, and your system grinds to a halt. Manual recovery is slow and prone to human error, which is why we need an automated supervisor: Sentinel.
How Sentinel Works
Sentinel is a distributed system that runs alongside your Redis instances. It performs three critical tasks:
- Monitoring: Sentinel constantly checks if your master and replica instances are working as expected.
- Notification: It alerts your application or system administrators via an API when something goes wrong.
- Automatic Failover: If a master is unreachable, Sentinel promotes one of the available replicas to become the new master and reconfigures the other replicas to replicate from this new leader.
The Failover Workflow
Imagine you have one master and two replicas. If the master experiences a hardware failure, Sentinel detects the timeout. Once a quorum of Sentinels agrees the master is "down," they trigger an election. One replica is promoted, and the application’s connection string is updated (or the application queries the Sentinel API to discover the new master address).
# Example: Connecting to a Sentinel-managed cluster
# The application asks Sentinel: "Who is the master?"
redis-cli -h sentinel-host -p 26379 SENTINEL get-master-addr-by-name mymaster
# Output returns the new IP/Port of the promoted master
By decoupling the "authority" of the master from a static IP address, you eliminate the need for manual intervention during downtime. Your application logic simply consults the Sentinel service to find the current source of truth, allowing your database infrastructure to self-heal.
Key Takeaway: Sentinel acts as an automated watchdog that detects primary node failure and promotes a replica to master, ensuring your database cluster survives outages without manual configuration changes.