Failover manual process in Redis - Step-by-Step Execution

Concept Flow - Failover manual process

Detect Master Failure

↓

Promote Slave to Master

↓

Update Clients to New Master

↓

Reconfigure Other Slaves

↓

Monitor New Master

↓

END

This flow shows the steps to manually handle failover in Redis by detecting failure, promoting a slave, updating clients, reconfiguring slaves, and monitoring.

Execution Sample

Redis

1. Check master status
2. Promote slave with 'SLAVEOF NO ONE'
3. Point clients to new master
4. Reconfigure other slaves
5. Monitor new master health

This sequence manually switches Redis roles to recover from master failure.

Execution Table

Step	Action	Command/Operation	Result/State Change
1	Detect Master Failure	Ping master or check logs	Master is unresponsive
2	Promote Slave to Master	SLAVEOF NO ONE on slave	Slave becomes new master
3	Update Clients	Change client config to new master IP	Clients connect to new master
4	Reconfigure Other Slaves	SLAVEOF new_master_ip on other slaves	Slaves replicate new master
5	Monitor New Master	Regular PING and logs	Ensure new master is stable
6	END	Manual failover complete	System running with new master

💡 Manual failover ends after new master is stable and clients are updated

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
Master Status	Responsive	Unresponsive	N/A	N/A	N/A	N/A
Slave Role	Slave	Slave	Master	Master	Master	Master
Client Connection	Master IP	Master IP	Master IP	New Master IP	New Master IP	New Master IP
Other Slaves Role	Slave	Slave	Slave	Slave	Slave of new master	Slave of new master

Key Moments - 3 Insights

Why do we run 'SLAVEOF NO ONE' on the slave?

Running 'SLAVEOF NO ONE' stops the slave from replicating and promotes it to master, as shown in execution_table step 2.

Why must clients be updated after promoting the new master?

Clients need to connect to the new master IP to read/write data correctly, as shown in execution_table step 3.

What happens if other slaves are not reconfigured?

They will still replicate the old master, causing data inconsistency. Step 4 shows reconfiguration to replicate the new master.

Visual Quiz - 3 Questions

Look at the execution_table, what command is used to promote a slave to master?

A SLAVEOF NO ONE

B SLAVEOF master_ip

C PING master

D CONFIG REWRITE

💡 Hint

Check step 2 in the execution_table where the slave is promoted.

At which step do clients start connecting to the new master?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Look at the 'Update Clients' action in the execution_table.

If the master is still responsive, what happens to the failover process?

A Clients update to new master

B Failover proceeds anyway

C Failover stops at step 1

D Slaves reconfigure

💡 Hint

Refer to the 'Detect Master Failure' step in execution_table and variable_tracker for Master Status.

Concept Snapshot

Failover manual process in Redis:
1. Detect master failure by pinging.
2. Promote a slave with 'SLAVEOF NO ONE'.
3. Update clients to new master IP.
4. Reconfigure other slaves to replicate new master.
5. Monitor new master health continuously.

Full Transcript

In Redis manual failover, first detect if the master is down by pinging or checking logs. If unresponsive, promote a slave to master by running 'SLAVEOF NO ONE' on it. Then update all clients to connect to this new master. Next, reconfigure other slaves to replicate from the new master. Finally, monitor the new master to ensure stability. This process ensures Redis continues working despite master failure.

Practice

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