Monitoring with Sentinel in Redis - Step-by-Step Execution

Concept Flow - Monitoring with Sentinel

Start Sentinel

↓

Sentinel monitors Redis instances

↓

Detects master failure?

No→Continue monitoring

Yes↓

Sentinel votes for failover

↓

Elect new master

↓

Update clients with new master info

↓

Resume monitoring

Sentinel continuously watches Redis servers, detects failures, elects a new master, and informs clients to keep the system running smoothly.

Execution Sample

Redis

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

This config sets up Sentinel to monitor a Redis master at 127.0.0.1:6379 with quorum 2 and failover timing.

Execution Table

Step	Action	Condition/Check	Result	System State Change
1	Sentinel starts monitoring master	Master reachable?	Yes	Monitoring active, no failover
2	Master stops responding	Master reachable?	No	Sentinel marks master as down
3	Sentinel nodes vote	Quorum reached?	Yes	Failover process initiated
4	Elect new master	Election complete?	Yes	New master assigned
5	Update clients	Clients notified?	Yes	Clients connect to new master
6	Resume monitoring	System stable?	Yes	Monitoring continues with new master
7	Master recovers	Master reachable?	Yes	Old master becomes replica
8	Exit	Failover complete and stable?	True	Sentinel continues monitoring

💡 Failover completes successfully and system stabilizes with new master

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 5	Final
master_status	up	down	down	down	down	replica
failover_initiated	false	false	true	true	true	false
current_master	original_master	original_master	original_master	new_master	new_master	new_master
clients_updated	false	false	false	false	true	true

Key Moments - 3 Insights

Why does Sentinel wait for votes before starting failover?

Sentinel waits for quorum votes (see Step 3) to avoid false failovers caused by temporary network issues.

What happens to the old master after failover?

After failover, the old master becomes a replica (see variable 'master_status' final value) to avoid split-brain.

How do clients know about the new master?

Sentinel updates clients after election (Step 5), so they connect to the new master automatically.

Visual Quiz - 3 Questions

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

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Check the 'Result' and 'System State Change' columns in Step 2

According to the variable tracker, what is the value of 'failover_initiated' after Step 3?

A false

B true

C undefined

D null

💡 Hint

Look at the 'failover_initiated' row under 'After Step 3' column

If the quorum was not reached at Step 3, what would happen next?

A Sentinel would continue monitoring without failover

B Failover would start anyway

C Clients would be immediately updated

D Old master would become replica

💡 Hint

Refer to the 'Condition/Check' and 'Result' columns at Step 3

Concept Snapshot

Sentinel monitors Redis masters continuously.
If master fails, Sentinel nodes vote (quorum) to confirm.
On quorum, failover elects a new master.
Clients are updated to connect to new master.
Old master becomes replica after recovery.
This ensures high availability automatically.

Full Transcript

Sentinel is a Redis tool that watches over Redis servers to keep them running smoothly. It checks if the master server is working. If the master stops responding, Sentinel nodes vote to confirm the failure. When enough nodes agree, Sentinel starts a failover process to pick a new master. Then, it tells all clients to use the new master. The old master becomes a replica to avoid conflicts. This process helps Redis stay available without manual intervention.

Practice

1. What is the main purpose of Redis Sentinel in monitoring?

easy

A. To provide a graphical user interface for Redis

B. To automatically detect Redis server failures and promote replicas

C. To increase Redis memory capacity

D. To store data persistently on disk

Solution

1. Step 1: Understand Sentinel's role

   Sentinel monitors Redis servers to detect failures automatically.

2. Step 2: Identify Sentinel's key feature

   It can promote replicas to master to keep Redis available during failures.

3. Final Answer:

   To automatically detect Redis server failures and promote replicas -> Option B

4. Quick Check:

   Sentinel monitors and promotes replicas [OK]

Hint: Sentinel watches and promotes Redis servers automatically [OK]

Common Mistakes:

• Confusing Sentinel with data storage
• Thinking Sentinel increases memory
• Assuming Sentinel provides GUI

2. Which command correctly tells Sentinel to monitor a Redis master named mymaster at IP 192.168.1.10 on port 6379 with quorum 2?

easy

A. sentinel monitor mymaster 192.168.1.10 6379

B. sentinel watch mymaster 192.168.1.10 6379 2

C. sentinel add mymaster 192.168.1.10 6379 2

D. sentinel monitor mymaster 192.168.1.10 6379 2

Solution

1. Step 1: Recall Sentinel monitor syntax

   The correct syntax is: sentinel monitor <name> <ip> <port> <quorum>.

2. Step 2: Match the command to syntax

   sentinel monitor mymaster 192.168.1.10 6379 2 matches the syntax exactly with all required parameters.

3. Final Answer:

   sentinel monitor mymaster 192.168.1.10 6379 2 -> Option D

4. Quick Check:

   Correct sentinel monitor syntax [OK]

Hint: Use 'sentinel monitor' with name, IP, port, quorum [OK]

Common Mistakes:

• Using 'sentinel watch' instead of 'monitor'
• Omitting quorum number
• Using 'sentinel add' which is invalid

3. Given the following Sentinel configuration snippet:

sentinel monitor mymaster 10.0.0.5 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000

What does the down-after-milliseconds setting control?

medium

A. Time Redis waits before shutting down

B. Time replicas wait before syncing

C. Time Sentinel waits before marking master as down

D. Time Sentinel waits before starting failover

Solution

1. Step 1: Understand 'down-after-milliseconds'

   This setting defines how long Sentinel waits to consider the master as unreachable.

2. Step 2: Match setting to behavior

   It controls the time Sentinel waits before marking the master as down.

3. Final Answer:

   Time Sentinel waits before marking master as down -> Option C

4. Quick Check:

   down-after-milliseconds = time to mark down [OK]

Hint: down-after-milliseconds sets master down detection time [OK]

Common Mistakes:

• Confusing with Redis shutdown time
• Thinking it controls replica sync delay
• Assuming it delays failover start

4. You configured Sentinel with:

sentinel monitor mymaster 10.0.0.5 6379 2

But Sentinel never triggers failover even when the master is down. What is a likely cause?

medium

A. Quorum is set too high for available Sentinels

B. Master IP address is incorrect

C. Sentinel service is not running

D. Redis master port is blocked by firewall

Solution

1. Step 1: Understand quorum role

   Quorum is the number of Sentinels that must agree master is down to trigger failover.

2. Step 2: Analyze failover condition

   If quorum is higher than available Sentinels, failover never triggers.

3. Final Answer:

   Quorum is set too high for available Sentinels -> Option A

4. Quick Check:

   Failover needs quorum Sentinels agreeing [OK]

Hint: Check quorum matches number of running Sentinels [OK]

Common Mistakes:

• Ignoring quorum size
• Assuming IP or port issues cause failover block
• Not verifying Sentinel service status

5. You have 3 Sentinel instances monitoring a Redis master with quorum 2. One Sentinel detects the master is down and starts failover, but the other two Sentinels disagree. What will happen?

hard

A. Failover will not proceed until at least 2 Sentinels agree

B. Failover proceeds immediately with one Sentinel's decision

C. Sentinel with disagreement will restart Redis master

D. All Sentinels shut down to avoid split-brain

Solution

1. Step 1: Understand quorum in failover

   Failover requires quorum number of Sentinels to agree master is down.

2. Step 2: Analyze scenario with 3 Sentinels and quorum 2

   Only one Sentinel detects down, so quorum not reached; failover waits.

3. Final Answer:

   Failover will not proceed until at least 2 Sentinels agree -> Option A

4. Quick Check:

   Failover needs quorum agreement [OK]

Hint: Failover needs quorum agreement, not just one Sentinel [OK]

Common Mistakes:

• Thinking one Sentinel can trigger failover alone
• Assuming Sentinels restart Redis master
• Believing Sentinels shut down on disagreement