Sentinel configuration in Redis - Step-by-Step Execution

Concept Flow - Sentinel configuration

Start Sentinel

↓

Load Config File

↓

Connect to Master

↓

Monitor Master & Slaves

↓

Detect Failover Conditions

↓

If Master Down?

No→Continue Monitoring

Yes↓

Elect New Master

↓

Reconfigure Slaves

↓

Notify Clients

↓

Continue Monitoring

Sentinel starts, loads config, monitors master and slaves, detects failures, triggers failover, and continues monitoring.

Execution Sample

Redis

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

Configures Sentinel to monitor a master Redis instance and sets failover parameters.

Execution Table

Step	Action	Evaluation	Result
1	Start Sentinel process	Sentinel reads config	Sentinel ready to monitor
2	Load 'sentinel monitor' config	Identify master 'mymaster' at 127.0.0.1:6379	Master registered for monitoring
3	Load 'down-after-milliseconds'	Set timeout to 5000 ms	Failure detection timer set
4	Load 'failover-timeout'	Set failover timeout to 60000 ms	Failover timing configured
5	Load 'parallel-syncs'	Set max parallel syncs to 1	Sync limit set
6	Connect to master and slaves	Connections established	Monitoring begins
7	Check master health	Master responds	Continue monitoring
8	Simulate master down	No response within 5000 ms	Mark master as down
9	Start failover election	Sentinels vote	New master elected
10	Reconfigure slaves	Slaves point to new master	Replication updated
11	Notify clients	Clients informed of new master	Clients reconnect
12	Continue monitoring	Sentinel resumes checks	System stable
13	Exit	No further actions	Sentinel runs continuously

💡 Sentinel runs continuously; exit here means end of this trace.

Variable Tracker

Variable	Start	After Step 2	After Step 8	After Step 9	Final
master_status	unknown	up	down	new_master_elected	new_master_elected
failover_timer	not set	not set	started	running	running
slave_config	default	default	default	reconfigured	reconfigured

Key Moments - 3 Insights

Why does Sentinel wait 5000 ms before marking the master as down?

Sentinel uses the 'down-after-milliseconds' setting (step 3 and 8) to avoid false alarms from temporary network issues.

How does Sentinel decide who becomes the new master?

Sentinel nodes vote during failover election (step 9) to choose the best candidate, ensuring a coordinated failover.

What happens to the slaves after a new master is elected?

Slaves are reconfigured to replicate from the new master (step 10), so data stays consistent.

Visual Quiz - 3 Questions

Look at the execution table, at which step does Sentinel mark the master as down?

A Step 8

B Step 9

C Step 7

D Step 10

💡 Hint

Check the 'Evaluation' column for 'No response within 5000 ms' in step 8.

According to variable_tracker, what is the 'master_status' after step 9?

A up

B down

C new_master_elected

D unknown

💡 Hint

Look at the 'master_status' row under 'After Step 9' column.

If 'parallel-syncs' was set to 2 instead of 1, which step would be affected?

A Step 3

B Step 5

C Step 9

D Step 11

💡 Hint

Refer to step 5 where 'parallel-syncs' is loaded and set.

Concept Snapshot

Sentinel configuration commands set monitoring and failover parameters.
Key commands: sentinel monitor, down-after-milliseconds, failover-timeout, parallel-syncs.
Sentinel monitors master and slaves, detects failures, triggers failover.
Failover includes electing new master, reconfiguring slaves, notifying clients.
Sentinel runs continuously to maintain Redis high availability.

Full Transcript

Sentinel configuration involves setting up monitoring for a Redis master instance and defining failover behavior. The process starts by loading configuration commands such as 'sentinel monitor' to specify the master, 'down-after-milliseconds' to set failure detection timeout, 'failover-timeout' for failover duration, and 'parallel-syncs' to limit slave synchronization. Sentinel connects to the master and slaves, continuously checking their health. If the master does not respond within the timeout, Sentinel marks it as down and initiates a failover election among Sentinel nodes. Once a new master is elected, slaves are reconfigured to replicate from it, and clients are notified to reconnect. This cycle repeats to ensure Redis availability.