Resharding hash slots in Redis - Step-by-Step Execution

Concept Flow - Resharding hash slots

Start: Cluster with N nodes

↓

Identify hash slots to move

↓

For each slot to move

↓

Set slot state to importing on target node

↓

Set slot state to migrating on source node

↓

Migrate keys in slot from source to target

↓

Update slot ownership to target node

↓

Repeat for all slots

↓

Cluster resharding complete

This flow shows how hash slots are moved from one Redis cluster node to another to balance data.

Execution Sample

Redis

CLUSTER SETSLOT 1234 IMPORTING <target-node-id>
CLUSTER SETSLOT 1234 MIGRATING <source-node-id>
MIGRATE <target-ip> <target-port> "" 0 5000 KEYS key1 key2
CLUSTER SETSLOT 1234 NODE <target-node-id>

Commands to move hash slot 1234 from source node to target node by setting states and migrating keys.

Execution Table

Step	Action	Slot State Source Node	Slot State Target Node	Keys Migrated	Result
1	Identify slot 1234 to move	Owned	Not owned	None	Ready to move slot 1234
2	Set slot 1234 IMPORTING on target node	Owned	IMPORTING	None	Target node ready to receive keys
3	Set slot 1234 MIGRATING on source node	MIGRATING	IMPORTING	None	Source node ready to send keys
4	Migrate keys key1, key2 from source to target	MIGRATING	IMPORTING	key1, key2	Keys moved successfully
5	Set slot 1234 ownership to target node	Not owned	Owned	All keys	Slot ownership updated
6	Repeat for other slots or finish	N/A	N/A	N/A	Resharding complete

💡 All selected slots moved and ownership updated; cluster balanced

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 5	Final
Slot 1234 State on Source Node	Owned	Owned	MIGRATING	MIGRATING	Not owned	Not owned
Slot 1234 State on Target Node	Not owned	IMPORTING	IMPORTING	IMPORTING	Owned	Owned
Keys in Slot 1234 on Source Node	key1, key2	key1, key2	key1, key2	None	None	None
Keys in Slot 1234 on Target Node	None	None	None	key1, key2	key1, key2	key1, key2

Key Moments - 3 Insights

Why do we set the slot state to IMPORTING on the target node before migrating keys?

Setting IMPORTING on the target node signals it to accept keys for that slot, ensuring keys are not lost during migration (see execution_table step 2).

What happens if we migrate keys before setting MIGRATING on the source node?

Without MIGRATING state on source, the source node might not allow key migration, causing errors or data inconsistency (see execution_table step 3).

Why do we update slot ownership only after migrating all keys?

Updating ownership too early could cause clients to send commands to the wrong node, leading to errors or lost data (see execution_table step 5).

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the source node stop owning the slot?

A Step 3

B Step 5

C Step 4

D Step 6

💡 Hint

Check the 'Slot State Source Node' column in execution_table rows

According to variable_tracker, after migrating keys, where are the keys located?

A Still on source node

B On both source and target nodes

C Only on target node

D Deleted from both nodes

💡 Hint

Look at 'Keys in Slot 1234 on Target Node' and 'Keys in Slot 1234 on Source Node' after Step 4

If we skipped setting IMPORTING on the target node, what would likely happen?

A Target node rejects incoming keys

B Keys migrate successfully anyway

C Source node refuses to migrate keys

D Slot ownership updates immediately

💡 Hint

Refer to key_moments about IMPORTING state importance and execution_table step 2

Concept Snapshot

Resharding hash slots moves data between Redis cluster nodes.
Steps: set IMPORTING on target, MIGRATING on source, migrate keys, update slot ownership.
This ensures no data loss and consistent cluster state.
Always migrate keys before changing ownership.
Use CLUSTER SETSLOT and MIGRATE commands.

Full Transcript

Resharding hash slots in Redis cluster involves moving data slots from one node to another to balance load. The process starts by identifying which slots to move. Then, the target node is set to IMPORTING state for those slots, signaling readiness to receive keys. The source node sets the slot to MIGRATING state, allowing keys to be sent. Keys belonging to the slot are migrated from source to target. After all keys are moved, the slot ownership is updated to the target node. This sequence prevents data loss and ensures clients access the correct node. The execution table shows each step's slot states and keys moved. Variable tracking confirms keys move from source to target. Key moments clarify why states must be set in order. The visual quiz tests understanding of slot ownership changes, key locations, and state importance. The snapshot summarizes the commands and order needed for safe resharding.

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