Bird
Raised Fist0
Redisquery~10 mins

Failover manual process in Redis - Interactive Code Practice

Choose your learning style10 modes available
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

Complete the command to check the role of the Redis instance.

Redis
redis-cli [1]
Drag options to blanks, or click blank then click option'
AINFO replication
BPING
CSET key value
DGET key
Attempts:
3 left
💡 Hint
Common Mistakes
Using PING does not show role information.
GET or SET commands do not provide replication info.
2fill in blank
medium

Complete the command to promote a slave to master by making it writable.

Redis
redis-cli [1]
Drag options to blanks, or click blank then click option'
ACONFIG SET slave-read-only no
BCONFIG SET slave-read-only yes
CSLAVEOF no one
DSLAVEOF master 6379
Attempts:
3 left
💡 Hint
Common Mistakes
Using SLAVEOF with a master address keeps the instance as a slave.
CONFIG SET slave-read-only no only changes read-only mode but does not promote.
3fill in blank
hard

Fix the error in the command to make the current master a slave of the new master at 192.168.1.10 port 6379.

Redis
redis-cli [1] 192.168.1.10 6379
Drag options to blanks, or click blank then click option'
ASLAVE
BSLAVEOF
CMASTEROF
DREPLICAOF
Attempts:
3 left
💡 Hint
Common Mistakes
Using SLAVE or MASTEROF commands which do not exist.
Using REPLICAOF in older Redis versions.
4fill in blank
hard

Fill both blanks to check the replication offset and connected slaves count.

Redis
redis-cli [1] | grep [2]
Drag options to blanks, or click blank then click option'
AINFO replication
BINFO server
Cconnected_slaves
Drole
Attempts:
3 left
💡 Hint
Common Mistakes
Using INFO server does not show replication details.
Filtering by role does not show slave count.
5fill in blank
hard

Fill all three blanks to reset the old master as a slave of the new master at 10.0.0.5 port 6380 and make it read-only.

Redis
redis-cli [1] 10.0.0.5 [2] && redis-cli [3] slave-read-only yes
Drag options to blanks, or click blank then click option'
ASLAVEOF
B6380
CCONFIG SET
Attempts:
3 left
💡 Hint
Common Mistakes
Using SLAVEOF instead of SLAVEOF.
Forgetting to set slave-read-only to yes.

Practice

(1/5)
1. What is the main purpose of performing a manual failover in a Redis cluster?
easy
A. To upgrade Redis to a new version automatically
B. To delete all data from the Redis cluster
C. To switch the Redis master to a backup to keep the service running
D. To backup Redis data to an external storage

Solution

  1. Step 1: Understand failover purpose

    Failover is used to switch the master node to a backup node when the master fails or needs maintenance.
  2. Step 2: Identify the correct purpose

    The goal is to keep the Redis service running without interruption by promoting a backup to master.
  3. Final Answer:

    To switch the Redis master to a backup to keep the service running -> Option C
  4. Quick Check:

    Failover = switch master to backup [OK]
Hint: Failover means switching master to backup to avoid downtime [OK]
Common Mistakes:
  • Confusing failover with data backup
  • Thinking failover upgrades Redis automatically
  • Assuming failover deletes data
2. Which command syntax is correct to trigger a manual failover on a Redis cluster node?
easy
A. redis-cli --failover cluster
B. redis-cli failover --cluster
C. redis-cli cluster --failover node
D. redis-cli --cluster failover

Solution

  1. Step 1: Recall the correct command format

    The correct syntax to trigger manual failover is using the cluster option with failover and the node ID.
  2. Step 2: Match the syntax

    Only redis-cli --cluster failover <node-id> matches the official Redis command format.
  3. Final Answer:

    redis-cli --cluster failover <node-id> -> Option D
  4. Quick Check:

    Correct failover command = redis-cli --cluster failover [OK]
Hint: Failover command starts with 'redis-cli --cluster failover' [OK]
Common Mistakes:
  • Mixing order of command options
  • Using failover without --cluster
  • Incorrect placement of node-id
3. Given the command redis-cli --cluster failover 07c37dfeb2352e03a5a5a3b8f8f8f8f8f8f8f8f8 is executed, what is the expected result?
medium
A. The cluster will shut down immediately
B. The specified node is promoted to master if it is a replica
C. The command will return a syntax error
D. The node will be removed from the cluster

Solution

  1. Step 1: Understand the failover command effect

    The command triggers a manual failover on the specified node, promoting it to master if it is a replica.
  2. Step 2: Eliminate incorrect outcomes

    The cluster does not shut down, no syntax error occurs, and the node is not removed by this command.
  3. Final Answer:

    The specified node is promoted to master if it is a replica -> Option B
  4. Quick Check:

    Failover promotes replica to master [OK]
Hint: Failover promotes replica node to master, no shutdown [OK]
Common Mistakes:
  • Thinking failover shuts down cluster
  • Expecting syntax error on correct command
  • Assuming node removal happens
4. You run redis-cli --cluster failover without specifying a node ID. What is the likely outcome?
medium
A. The command returns an error about missing node ID
B. Manual failover is triggered on all nodes
C. The cluster automatically selects a node for failover
D. The command silently does nothing

Solution

  1. Step 1: Check command requirements

    The failover command requires a node ID to specify which node to promote.
  2. Step 2: Predict command behavior without node ID

    Without the node ID, the command will return an error indicating the missing argument.
  3. Final Answer:

    The command returns an error about missing node ID -> Option A
  4. Quick Check:

    Missing node ID causes error [OK]
Hint: Failover needs node ID; missing it causes error [OK]
Common Mistakes:
  • Assuming failover runs on all nodes
  • Expecting automatic node selection
  • Thinking command does nothing silently
5. After triggering a manual failover with redis-cli --cluster failover <node-id>, what is the best practice to ensure the cluster is stable?
hard
A. Confirm the new master node is ready to serve data
B. Immediately restart all cluster nodes
C. Delete the old master node from the cluster
D. Run a full data backup before any verification

Solution

  1. Step 1: Understand post-failover steps

    After failover, the new master must be confirmed to be ready to serve data to avoid downtime or data loss.
  2. Step 2: Evaluate other options

    Restarting all nodes or deleting old master is unnecessary and risky; backup is good but not immediate priority.
  3. Final Answer:

    Confirm the new master node is ready to serve data -> Option A
  4. Quick Check:

    Verify new master readiness after failover [OK]
Hint: Always check new master readiness after failover [OK]
Common Mistakes:
  • Restarting cluster unnecessarily
  • Deleting old master prematurely
  • Ignoring verification step
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard