Resharding & Scaling

One of the main promises of Redis Cluster is the ability to add or remove nodes without downtime. This process is called Resharding.

1. The Resharding Process

Imagine you have 3 nodes, each holding ~5,461 slots. You want to add a 4th node. To balance the cluster, you need to move some slots from the existing nodes to the new node.

This process happens in 3 phases per slot:

  1. Set State:
    • Target Node is set to IMPORTING state for the slot.
    • Source Node is set to MIGRATING state for the slot.
  2. Move Keys:
    • A script (like redis-cli --cluster reshard) iterates over keys in that slot.
    • It sends MIGRATE commands to move keys atomically from Source to Target.
  3. Finalize:
    • Once all keys are moved, the slot ownership is officially transferred.
    • Gossip propagates the new config (Source Node no longer owns the slot).

2. Handling Traffic During Migration

This is where the ASK redirection comes in.

  • Request to Source: If the key is still there, it answers. If the key has moved, it returns -ASK TargetNode.
  • Request to Target: Usually, the target rejects keys for slots it doesn’t officially own yet. But if the client sends an ASKING command first (which follows the ASK redirect), the target accepts the request.

3. Interactive: Slot Migration

Visualize moving Slot 100 from Node A to Node B.

Status: Idle
Node A
Owner: Slot 100
user:1
user:2
user:3
→
Node B
Target

4. Key Takeaways

  • Zero Downtime: The cluster remains available during migration.
  • Atomic Key Moves: Keys are locked for a brief moment while moving, ensuring consistency.
  • Smart Redirection: Clients are guided to the right node via ASK if they hit the wrong one during the transition.