Resharding hash slots in Redis - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

What is the output of the resharding command status?

After initiating a resharding operation in Redis Cluster, you run the command CLUSTER RESHARDING STATUS. What output do you expect if the resharding is currently moving slots?

A An error message stating the command is unknown

B An empty list indicating no resharding in progress

C A list showing the number of slots moved and the total slots to move

D A string with the cluster node IDs only

💡 Hint

Think about what information you want to see during resharding progress.

The CLUSTER RESHARDING STATUS command does not exist in Redis. Resharding progress is typically monitored via redis-cli or external tools.

🧠 Conceptual

intermediate

Why is resharding hash slots necessary in Redis Cluster?

Which of the following best explains why you would perform resharding of hash slots in a Redis Cluster?

A To encrypt data stored in hash slots

B To clear all data from the cluster quickly

C To upgrade Redis version on all nodes simultaneously

D To rebalance data when adding or removing nodes to maintain even load

💡 Hint

Think about cluster scaling and data distribution.

Resharding moves hash slots between nodes to balance data and load, especially when nodes are added or removed.

📝 Syntax

advanced

Which command syntax correctly moves 50 hash slots from one node to another?

You want to move 50 hash slots from node A to node B in a Redis Cluster. Which command syntax is correct?

A redis-cli --cluster reshard <cluster_ip>:<port> --slots 50 --from <nodeA_id> --to <nodeB_id>

B CLUSTER RESHARD --slots 50 --from <nodeA_id> --to <nodeB_id>

C CLUSTER SETSLOT 50 NODE <nodeB_id>

D CLUSTER MOVE 50 FROM <nodeA_id> TO <nodeB_id>

💡 Hint

Consider the official redis-cli cluster management commands.

The redis-cli --cluster reshard command with appropriate flags is the correct way to reshard slots between nodes.

🔧 Debug

advanced

Why does the resharding command fail with 'MOVED' error?

You run the resharding command to move slots but get an error: MOVED 1234 10.0.0.2:7002. What is the most likely cause?

A The Redis version is incompatible with resharding

B The slots you want to move are already moved

C You are connected to a node that does not own the slots you want to move

D The cluster is down and cannot process commands

💡 Hint

The MOVED error indicates a redirection in Redis Cluster.

The MOVED error means the command was sent to a node that does not own the requested slot, so you must connect to the correct node to reshard.

❓ optimization

expert

How to minimize downtime during resharding in a large Redis Cluster?

You have a large Redis Cluster and want to reshard hash slots with minimal downtime. Which approach is best?

A Stop all clients, move all slots at once, then restart clients

B Use the redis-cli reshard command with small batch sizes and monitor progress

C Manually edit cluster configuration files to reassign slots instantly

D Restart all nodes sequentially during resharding

💡 Hint

Think about gradual data movement and client availability.

Moving slots in small batches with redis-cli reshard allows the cluster to remain available and reduces downtime.

Practice

1. What is the main purpose of resharding hash slots in a Redis cluster?

easy

A. To balance data evenly across cluster nodes

B. To delete unused keys from the database

C. To backup data to an external storage

D. To increase the size of each hash slot

Solution

1. Step 1: Understand hash slots in Redis cluster

   Redis cluster divides data into 16384 hash slots distributed among nodes.

2. Step 2: Purpose of resharding

   Resharding moves hash slots to balance load and storage evenly across nodes.

3. Final Answer:

   To balance data evenly across cluster nodes -> Option A

4. Quick Check:

   Resharding = balance data [OK]

Hint: Resharding means redistributing data evenly [OK]

Common Mistakes:

• Thinking resharding deletes keys
• Confusing resharding with backup
• Assuming hash slot size changes

2. Which Redis command is used to mark a hash slot as migrating during resharding?

easy

A. CLUSTER ADDSLOTS <slot>

B. CLUSTER SETSLOT <slot> MIGRATING <node_id>

C. CLUSTER DELSLOTS <slot>

D. CLUSTER INFO

Solution

1. Step 1: Identify commands related to slot state changes

   CLUSTER SETSLOT command changes slot ownership or state.

2. Step 2: Marking migrating slot

   Using MIGRATING flag with CLUSTER SETSLOT marks slot as migrating from a node.

3. Final Answer:

   CLUSTER SETSLOT <slot> MIGRATING <node_id> -> Option B

4. Quick Check:

   MIGRATING slot = CLUSTER SETSLOT MIGRATING [OK]

Hint: Use CLUSTER SETSLOT with MIGRATING to mark slot move [OK]

Common Mistakes:

• Using ADDSLOTS or DELSLOTS instead of SETSLOT
• Confusing INFO command with slot state change
• Omitting node_id in command

3. Given the following commands during resharding, what is the correct order to migrate a hash slot 5000 from node A to node B?

1. CLUSTER SETSLOT 5000 MIGRATING nodeB_id
2. MIGRATE nodeB_ip 6379 "" 0 5000
3. CLUSTER SETSLOT 5000 IMPORTING nodeA_id
4. CLUSTER SETSLOT 5000 NODE nodeB_id

medium

A. 1, 2, 3, 4

B. 3, 1, 2, 4

C. 2, 1, 3, 4

D. 1, 3, 2, 4

Solution

1. Step 1: Mark slot as migrating on source node

   Use CLUSTER SETSLOT 5000 MIGRATING nodeB_id to mark slot migrating from node A.

2. Step 2: Mark slot as importing on destination node

   Use CLUSTER SETSLOT 5000 IMPORTING nodeA_id on node B to accept keys.

3. Step 3: Migrate keys with MIGRATE command

   Use MIGRATE to move keys of slot 5000 from node A to node B.

4. Step 4: Assign slot ownership to destination node

   Use CLUSTER SETSLOT 5000 NODE nodeB_id to finalize ownership.

5. Final Answer:

   1, 3, 2, 4 -> Option D

6. Quick Check:

   Mark migrating -> mark importing -> migrate keys -> assign slot [OK]

Hint: MIGRATING then IMPORTING before MIGRATE command [OK]

Common Mistakes:

• Migrating keys before marking IMPORTING
• Assigning slot ownership before migration
• Skipping IMPORTING step

4. You run the following commands to reshard slot 7000 but keys are not migrating correctly:

CLUSTER SETSLOT 7000 MIGRATING nodeB_id
MIGRATE nodeB_ip 6379 "" 0 7000
CLUSTER SETSLOT 7000 NODE nodeB_id

What is missing to fix the migration?

medium

A. Mark slot as IMPORTING on node B before MIGRATE

B. Run CLUSTER DELSLOTS 7000 on node A first

C. Use CLUSTER ADDSLOTS 7000 on node B after migration

D. Restart both nodes before migration

Solution

1. Step 1: Identify missing IMPORTING state

   Destination node must mark slot as IMPORTING before receiving keys.

2. Step 2: Add missing command

   Use CLUSTER SETSLOT 7000 IMPORTING nodeA_id on node B before MIGRATE.

3. Final Answer:

   Mark slot as IMPORTING on node B before MIGRATE -> Option A

4. Quick Check:

   IMPORTING state needed on destination [OK]

Hint: Always mark IMPORTING on target node before MIGRATE [OK]

Common Mistakes:

• Skipping IMPORTING step
• Deleting slots prematurely
• Restarting nodes unnecessarily

5. During a large-scale resharding, you want to move multiple hash slots from node A to node B without downtime. Which sequence of actions ensures data consistency and minimal disruption?

hard

A. Assign slots to node B first, then migrate keys, finally mark MIGRATING on node A

B. Migrate keys first, then mark slots IMPORTING on node B, finally mark MIGRATING on node A

C. Mark slots MIGRATING on node A, mark IMPORTING on node B, migrate keys, then assign slots to node B

D. Delete slots on node A, migrate keys, then assign slots to node B

Solution

1. Step 1: Mark slots as MIGRATING on source node

   This prevents writes to those slots on node A during migration.

2. Step 2: Mark slots as IMPORTING on destination node

   Allows node B to accept keys for those slots.

3. Step 3: Migrate keys using MIGRATE command

   Safely transfer keys from node A to node B.

4. Step 4: Assign slots ownership to node B

   Finalizes the slot ownership after migration completes.

5. Final Answer:

   Mark slots MIGRATING on node A, mark IMPORTING on node B, migrate keys, then assign slots to node B -> Option C

6. Quick Check:

   MIGRATING -> IMPORTING -> MIGRATE -> ASSIGN [OK]

Hint: Follow MIGRATING, IMPORTING, MIGRATE, then assign slots [OK]

Common Mistakes:

• Assigning slots before migration
• Migrating keys without marking IMPORTING
• Deleting slots before migration