Multiple Sentinel instances in Redis - Step-by-Step Execution

Concept Flow - Multiple Sentinel instances

Start: Deploy Sentinel Instances

↓

Each Sentinel monitors Master

↓

Sentinels communicate with each other

↓

Detect Master failure?

No→Continue monitoring

Yes↓

Sentinels agree on failover

↓

Promote a Slave to Master

↓

Update configuration and notify clients

↓

Sentinels continue monitoring new Master

Multiple Sentinel instances run independently but communicate to monitor the master, detect failures, agree on failover, and promote a slave to master.

Execution Sample

Redis

# Sentinel instances monitor master
sentinel1 monitor master 127.0.0.1 6379 2
sentinel2 monitor master 127.0.0.1 6379 2
sentinel3 monitor master 127.0.0.1 6379 2

# Sentinels communicate and decide failover
# Promote slave if master down

This setup shows three Sentinel instances monitoring the same master and coordinating failover.

Execution Table

Step	Sentinel Instance	Action	State Change	Result
1	sentinel1	Start monitoring master	Monitoring master at 127.0.0.1:6379	Sentinel1 active
2	sentinel2	Start monitoring master	Monitoring master at 127.0.0.1:6379	Sentinel2 active
3	sentinel3	Start monitoring master	Monitoring master at 127.0.0.1:6379	Sentinel3 active
4	All Sentinels	Exchange info	Share master status	Consensus on master health
5	All Sentinels	Detect master failure	Master unreachable	Failover condition met
6	All Sentinels	Vote for failover	Majority agree failover	Failover approved
7	All Sentinels	Promote slave	One slave promoted to master	New master active
8	All Sentinels	Notify clients	Clients updated with new master	Clients reconnect
9	All Sentinels	Continue monitoring	Monitoring new master	System stable
10	-	-	-	Execution ends: failover complete and monitoring continues

💡 Failover completed after majority Sentinel agreement and new master promotion

Variable Tracker

Variable	Start	After Step 4	After Step 6	After Step 7	Final
Master Status	Up	Up	Down	New Master Up	New Master Up
Sentinel Consensus	None	Healthy	Failover Approved	Failover Done	Monitoring New Master
Promoted Node	None	None	None	Slave1	Slave1

Key Moments - 3 Insights

Why do multiple Sentinels communicate before failover?

They share master status to reach a majority agreement, preventing false failovers (see execution_table step 4 and 6).

What happens if only one Sentinel detects failure?

Failover does not proceed until majority agree, so monitoring continues (see execution_table step 5 and 6).

How do Sentinels know which slave to promote?

They coordinate and select the best slave based on configuration and health (see execution_table step 7).

Visual Quiz - 3 Questions

Look at the execution_table, at which step do Sentinels agree to start failover?

A Step 6

B Step 4

C Step 5

D Step 7

💡 Hint

Check the 'Action' and 'Result' columns for voting and approval in execution_table step 6.

According to variable_tracker, what is the Master Status after step 7?

A Up

B Down

C New Master Up

D Unknown

💡 Hint

Look at 'Master Status' row in variable_tracker after step 7.

If Sentinel2 did not start monitoring at step 2, how would the failover process change?

A Failover would require manual intervention

B Failover would still proceed with two Sentinels

C Failover would never start

D Sentinel1 would promote itself immediately

💡 Hint

Refer to execution_table steps 1-3 and understand that majority agreement is needed, so two Sentinels can still form majority.

Concept Snapshot

Multiple Sentinel instances run independently but communicate to monitor the master.
They detect failures by exchanging info and agree by majority vote.
On failover, Sentinels promote a slave to master and notify clients.
This coordination prevents false failovers and ensures high availability.

Full Transcript

Multiple Sentinel instances monitor the Redis master independently. They communicate regularly to share the master's health status. When a failure is detected, Sentinels vote to confirm the failure before starting failover. Once a majority agrees, they promote a slave to master and update clients. This process ensures reliable failover and continuous monitoring of the new master.