Automatic failover in Redis - Step-by-Step Execution

Concept Flow - Automatic failover

Primary Redis Server

↓

Health Check by Sentinel

↓

Continue

↓

Replica Becomes New Primary

↓

Clients Redirected to New Primary

The Sentinel monitors the primary Redis server. If it detects failure, it promotes a replica to primary and redirects clients automatically.

Execution Sample

Redis

SENTINEL MONITOR mymaster 127.0.0.1 6379 2
SENTINEL FAILOVER mymaster

Sentinel monitors the primary Redis server and triggers failover to a replica if needed.

Execution Table

Step	Action	Condition	Result	Notes
1	Sentinel checks primary server	Primary responds	No failover	Primary is healthy
2	Sentinel checks primary server	Primary does not respond	Failover triggered	Primary is down
3	Sentinel selects replica	Replica is reachable	Replica promoted	Replica becomes new primary
4	Clients redirected	Clients connect to new primary	Operations continue	Failover complete
5	Sentinel continues monitoring	New primary responds	System stable	Monitoring resumes

💡 Failover completes when a replica is promoted and clients connect to it successfully.

Variable Tracker

Variable	Start	After Step 2	After Step 3	Final
Primary Status	Alive	Down	Down	Down
Replica Status	Replica	Replica	Promoted to Primary	Primary
Client Connection	Primary	Primary (failed)	Switching	New Primary

Key Moments - 3 Insights

Why does Sentinel promote a replica instead of restarting the primary?

Sentinel promotes a replica because the primary is unresponsive (see execution_table step 2), ensuring minimal downtime by switching to a healthy server.

How do clients know to connect to the new primary?

Clients are redirected after failover (execution_table step 4) because Sentinel updates the configuration or clients query Sentinel to find the current primary.

What happens if no replicas are available during failover?

Failover cannot complete without a reachable replica (execution_table step 3), so the system remains down until a replica is available.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does Sentinel detect the primary is down?

A Step 2

B Step 3

C Step 1

D Step 4

💡 Hint

Check the 'Condition' and 'Result' columns in step 2 for primary server status.

According to variable_tracker, what is the status of the replica after step 3?

A Down

B Promoted to Primary

C Still a replica

D Disconnected

💡 Hint

Look at the 'Replica Status' row after step 3 in variable_tracker.

If the primary server never fails, what will the failover process do?

A Promote a replica anyway

B Clients will be redirected

C Failover will not trigger

D Sentinel stops monitoring

💡 Hint

Refer to execution_table step 1 where primary responds and no failover occurs.

Concept Snapshot

Automatic failover in Redis Sentinel:
- Sentinel monitors primary Redis server health.
- If primary fails, Sentinel promotes a replica to primary.
- Clients are redirected to the new primary automatically.
- Ensures high availability with minimal downtime.
- Requires at least one healthy replica for failover.

Full Transcript

Automatic failover in Redis works by Sentinel continuously checking if the primary Redis server is alive. If Sentinel detects the primary is down, it promotes one of the replicas to become the new primary. Then, clients are redirected to connect to this new primary so operations can continue without interruption. This process ensures the system stays available even if the main server fails. Sentinel keeps monitoring the new primary to maintain system stability.

Practice

1. What is the main purpose of automatic failover in Redis?

easy

A. To backup data to an external storage

B. To increase the speed of Redis queries

C. To switch to a backup server if the main server fails

D. To encrypt data during transmission

Solution

1. Step 1: Understand the concept of failover

   Failover means switching to a backup system when the main one stops working.

2. Step 2: Apply this to Redis context

   Redis automatic failover switches to a backup Redis server if the main one fails.

3. Final Answer:

   To switch to a backup server if the main server fails -> Option C

4. Quick Check:

   Automatic failover = switch to backup server [OK]

Hint: Failover means backup server takes over on failure [OK]

Common Mistakes:

• Confusing failover with data backup
• Thinking failover speeds up queries
• Mixing failover with encryption

2. Which Redis component is responsible for managing automatic failover?

easy

A. Redis Cluster

B. Redis Sentinel

C. Redis Streams

D. Redis Modules

Solution

1. Step 1: Identify Redis components related to failover

   Redis Sentinel is designed to monitor Redis servers and manage failover.

2. Step 2: Confirm other options are unrelated

   Redis Cluster manages sharding, Streams handle data streams, Modules add features but don't manage failover.

3. Final Answer:

   Redis Sentinel -> Option B

4. Quick Check:

   Failover manager = Sentinel [OK]

Hint: Sentinel monitors and triggers failover in Redis [OK]

Common Mistakes:

• Confusing Sentinel with Cluster
• Thinking Streams handle failover
• Assuming Modules manage failover

3. Given a Redis setup with 3 Sentinel instances monitoring 1 master and 2 replicas, what happens if the master fails?

medium

A. Sentinels promote one replica to master automatically

B. All Sentinels shut down to prevent split-brain

C. Clients lose connection permanently

D. The master restarts automatically without promotion

Solution

1. Step 1: Understand Sentinel quorum and failover

   With multiple Sentinels, they agree on master failure and promote a replica.

2. Step 2: Analyze options

   Sentinels do not shut down; clients reconnect after failover; master does not restart automatically.

3. Final Answer:

   Sentinels promote one replica to master automatically -> Option A

4. Quick Check:

   Master failure triggers replica promotion [OK]

Hint: Sentinels elect new master when original fails [OK]

Common Mistakes:

• Thinking Sentinels shut down on failure
• Assuming clients lose connection forever
• Believing master restarts without failover

4. You configured Redis Sentinel with only one instance monitoring a master and replicas. What is a likely problem with automatic failover?

medium

A. Failover may not happen due to lack of quorum

B. Sentinel will promote multiple replicas simultaneously

C. Sentinel will delete all data on replicas

D. Failover will happen instantly without checks

Solution

1. Step 1: Understand Sentinel quorum requirement

   Sentinel needs multiple instances to agree (quorum) before failover.

2. Step 2: Analyze single Sentinel behavior

   With only one Sentinel, no quorum exists, so failover may not trigger reliably.

3. Final Answer:

   Failover may not happen due to lack of quorum -> Option A

4. Quick Check:

   Single Sentinel lacks quorum for failover [OK]

Hint: Multiple Sentinels needed for reliable failover [OK]

Common Mistakes:

• Thinking one Sentinel can safely failover
• Believing Sentinel deletes replica data
• Assuming failover is instant without checks

5. In a Redis master-replica setup with automatic failover, which combination ensures the highest availability?

hard

A. One master, no replicas, one Sentinel instance

B. One master, one replica, one Sentinel instance

C. Multiple masters, no replicas, multiple Sentinel instances

D. One master, multiple replicas, multiple Sentinel instances

Solution

1. Step 1: Identify components for high availability

   Multiple replicas provide backup data; multiple Sentinels provide reliable failover decisions.

2. Step 2: Evaluate each option

   One master, one replica, one Sentinel instance lacks multiple Sentinels; C has multiple masters causing conflicts; D lacks replicas and multiple Sentinels.

3. Final Answer:

   One master, multiple replicas, multiple Sentinel instances -> Option D

4. Quick Check:

   Replicas + multiple Sentinels = high availability [OK]

Hint: Use multiple replicas and Sentinels for best failover [OK]

Common Mistakes:

• Thinking one Sentinel is enough
• Confusing multiple masters with high availability
• Ignoring replicas in failover setup