Cluster failover in Redis - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the command to check the cluster nodes status.

Redis

redis-cli [1]

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

ACLUSTER NODES

BPING

CINFO

DGET

Attempts:

3 left

💡 Hint

Common Mistakes

Using INFO instead of CLUSTER NODES.

Using PING which only checks connectivity.

Using GET which is for keys, not cluster info.

The CLUSTER NODES command lists all nodes in the Redis cluster and their status.

2fill in blank

medium

Complete the command to trigger a manual failover on a Redis replica node.

Redis

redis-cli [1] FAILOVER

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

ACLUSTER

BREPLICA

CFAILOVER

DSLAVEOF

Attempts:

3 left

💡 Hint

Common Mistakes

Using REPLICA FAILOVER which is not a valid command.

Using FAILOVER alone without CLUSTER prefix.

Using SLAVEOF which is deprecated in cluster mode.

The CLUSTER FAILOVER command forces a replica to become a master during failover.

3fill in blank

hard

Fix the error in the command to check cluster slots allocation.

Redis

redis-cli [1] SLOTS

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

ANODES

BSLOT

CCLUSTER

DINFO

Attempts:

3 left

💡 Hint

Common Mistakes

Using SLOT instead of SLOTS.

Using INFO which does not show slots.

Using NODES which shows node info but not slots.

The correct command is CLUSTER SLOTS to view slot allocation in the cluster.

4fill in blank

hard

Fill both blanks to create a command that sets a node as a replica of another node.

Redis

redis-cli [1] [2] <master-node-id>

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

ACLUSTER

BREPLICAOF

CFAILOVER

DREPLICATE

Attempts:

3 left

💡 Hint

Common Mistakes

Using REPLICAOF which is not valid in cluster mode.

Using FAILOVER which triggers failover but does not assign master.

Using REPLICAOF alone without CLUSTER prefix.

The command CLUSTER REPLICATE <master-node-id> sets the current node as a replica of the specified master node.

5fill in blank

hard

Fill all three blanks to create a command that forces a replica to failover and become master immediately.

Redis

redis-cli [1] FAILOVER [2] [3]

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

ACLUSTER

BFORCE

CTAKEOVER

DABORT

Attempts:

3 left

💡 Hint

Common Mistakes

Using ABORT which cancels failover.

Omitting FORCE or TAKEOVER which delays failover.

Using FAILOVER alone without options.

The command CLUSTER FAILOVER FORCE TAKEOVER forces a replica to become master immediately, even if the master is still reachable.

Practice

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

easy

A. To backup data to an external storage

B. To clear all keys from the database

C. To increase the number of replicas manually

D. To switch a replica to master if the current master fails

Solution

1. Step 1: Understand cluster failover concept

   Cluster failover automatically promotes a replica to master when the current master fails.

2. Step 2: Identify the main purpose

   This process ensures Redis availability without manual intervention.

3. Final Answer:

   To switch a replica to master if the current master fails -> Option D

4. Quick Check:

   Failover = switch replica to master [OK]

Hint: Failover means replica becomes master on failure [OK]

Common Mistakes:

• Confusing failover with backup
• Thinking failover increases replicas
• Assuming failover clears data

2. Which Redis command syntax correctly triggers a manual failover on a replica node?

easy

A. CLUSTER FAILOVER

B. FAILOVER CLUSTER

C. CLUSTER FAILOVER NOW

D. FAILOVER REPLICA

Solution

1. Step 1: Recall Redis failover command syntax

   The correct command to trigger failover is CLUSTER FAILOVER.

2. Step 2: Check options for syntax correctness

   Options B, C, and D are invalid Redis commands or incorrect order.

3. Final Answer:

   CLUSTER FAILOVER -> Option A

4. Quick Check:

   Correct command = CLUSTER FAILOVER [OK]

Hint: Remember command starts with CLUSTER then FAILOVER [OK]

Common Mistakes:

• Swapping command words order
• Adding invalid keywords
• Using non-existent commands

3. Given a Redis cluster where the master node fails, what will happen if you run CLUSTER FAILOVER FORCE on a replica?

medium

A. The replica deletes all its data before failing over

B. The replica waits for the master to recover before failing over

C. The replica immediately becomes master regardless of cluster state

D. The command returns an error because FORCE is invalid

Solution

1. Step 1: Understand FORCE option in failover

   FORCE forces the replica to become master immediately, ignoring cluster state.

2. Step 2: Analyze other options

   Waiting for master recovery is default without FORCE; FORCE does not cause errors or data deletion.

3. Final Answer:

   The replica immediately becomes master regardless of cluster state -> Option C

4. Quick Check:

   FORCE = immediate failover [OK]

Hint: FORCE triggers instant failover ignoring cluster state [OK]

Common Mistakes:

• Thinking FORCE waits for master
• Assuming FORCE causes errors
• Believing FORCE deletes data

4. You tried running CLUSTER FAILOVER TAKEOVER on a replica but got an error. What is the most likely cause?

medium

A. The TAKEOVER option is not supported in Redis

B. The replica is not connected to the cluster

C. The replica is already the master

D. The command syntax is incorrect

Solution

1. Step 1: Understand TAKEOVER option requirements

   TAKEOVER forces failover even if the master is alive but requires cluster connectivity.

2. Step 2: Identify error cause

   If the replica is disconnected, the command fails with an error.

3. Final Answer:

   The replica is not connected to the cluster -> Option B

4. Quick Check:

   Disconnected replica causes TAKEOVER error [OK]

Hint: Replica must be connected for TAKEOVER to work [OK]

Common Mistakes:

• Assuming TAKEOVER is unsupported
• Ignoring replica connection status
• Thinking syntax is wrong

5. In a Redis cluster with multiple replicas, which failover option should you use to safely promote a replica without risking data loss, and why?

hard

A. Use CLUSTER FAILOVER without options to allow safe automatic failover

B. Use CLUSTER FAILOVER FORCE to force immediate promotion regardless of state

C. Use CLUSTER FAILOVER TAKEOVER to take over even if master is alive

D. Manually disconnect the master before failover

Solution

1. Step 1: Review failover options and safety

   Default CLUSTER FAILOVER waits for safe conditions, avoiding data loss.

2. Step 2: Compare with FORCE and TAKEOVER risks

   FORCE and TAKEOVER can cause data loss by ignoring cluster state or master status.

3. Step 3: Consider manual disconnection risks

   Manually disconnecting master is risky and not recommended for safe failover.

4. Final Answer:

   Use CLUSTER FAILOVER without options to allow safe automatic failover -> Option A

5. Quick Check:

   Safe failover = default CLUSTER FAILOVER [OK]

Hint: Default failover is safest to avoid data loss [OK]

Common Mistakes:

• Using FORCE or TAKEOVER without understanding risks
• Manually disconnecting master unnecessarily
• Assuming all failover options are equally safe