Automatic failover in Redis - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to check the role of a Redis node.

Redis

[1]

Drag options to blanks, or click blank then click option'

AINFO

BROLE

CPING

DCONFIG

Attempts:

3 left

💡 Hint

Common Mistakes

Using INFO instead of ROLE

Using PING which only checks connectivity

The ROLE command returns the role of the Redis node (master, slave, or sentinel).

2fill in blank

medium

Complete the command to failover a Redis slave to master.

Redis

SLAVEOF [1] [2]

Drag options to blanks, or click blank then click option'

ANO

B127.0.0.1

CONE

Dlocalhost

Attempts:

3 left

💡 Hint

Common Mistakes

Using IP address instead of NO ONE

Using a port number instead of ONE

The command SLAVEOF NO ONE makes the slave become master.

3fill in blank

hard

Fix the error in the command to trigger a manual failover in Redis Sentinel.

Redis

SENTINEL [1] mymaster

Drag options to blanks, or click blank then click option'

Afailovered

Bfailovering

Cfailover

Dfailovers

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'failovering' or 'failovered' which are invalid commands

The correct command to trigger a manual failover in Redis Sentinel is SENTINEL failover <master-name>.

4fill in blank

hard

Fill both blanks to configure Redis Sentinel to monitor a master.

Redis

SENTINEL MONITOR [1] [2] 6379 2

Drag options to blanks, or click blank then click option'

Amymaster

B127.0.0.1

C192.168.1.100

Dlocalhost

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'localhost' instead of the actual IP

Using wrong master name

The SENTINEL MONITOR command requires the master name and IP address. Here, 'mymaster' is the master name and '192.168.1.100' is the IP.

5fill in blank

hard

Fill all three blanks to check the current master of a monitored Redis master in Sentinel.

Redis

SENTINEL [1] | grep {{BLANK_3}}

Drag options to blanks, or click blank then click option'

Amasters

Bmymaster

Cname

Dslaves

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'slaves' instead of 'masters'

Using wrong grep keyword

The command SENTINEL masters mymaster lists masters, and piping to grep name filters the master name.

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