The Error ScenarioYou are scaling your Redis Cluster by adding a fourth node or rebalancing 16,384 slots to handle a traffic spike. Suddenly, your application logs spike with a specific failure: (error) TRYAGAIN Multiple keys request during rehashing of slot. This usually halts operations for any command involving multiple keys, such as MGET, MSET, or custom Lua scripts.
This error happens when a command targets multiple keys that live in the same hash slot, but that slot is currently migrating between nodes. Redis cannot guarantee atomicity when the data is split between a source and a destination node.
Why This HappensRedis Cluster partitions data into 16,384 hash slots. When you migrate a slot from Node A to Node B, the slot enters a "migrating" state on the source and an "importing" state on the destination. During this transition, keys are moved in batches.
Single-key commands are easy to handle. If the key is gone, Node A sends an ASK redirection, and the client retries on Node B. Multi-key commands are different. If your MGET requests 10 keys, and 7 have moved to Node B while 3 remain on Node A, Redis cannot process the request on either node. Rather than returning partial or inconsistent data, Redis throws the TRYAGAIN error. It is essentially asking the client to wait until the migration of that specific batch is complete.
Step 1: Identify the Migrating SlotTo fix the issue, you must first locate the slot stuck in transition. Run this command on any cluster node to see which slots are currently moving:
redis-cli -p 6379 CLUSTER NODES | grep -E "importing|migrating"
Your output will look like this:
node_id_1 192.168.1.10:6379@16379 master - 0 1625000000000 2 connected 0-5460 [5461->-node_id_2]
node_id_2 192.168.1.11:6379@16379 master - 0 1625000000000 3 connected 5462-10922 [5461-<-node_id_1]
In this specific case, slot 5461 is mid-migration. Any multi-key command hitting keys within slot 5461 will fail until the move finishes.
Step 2: Implement Application-Side Retry LogicBecause TRYAGAIN is a transient error, it usually resolves in milliseconds. Unlike a MOVED error, which implies a permanent topology change, TRYAGAIN just requires a brief pause. If you are using Python (redis-py), wrap your multi-key calls in a retry loop.
import time
import redis
def execute_with_retry(client, keys, max_retries=5):
attempt = 0
while attempt < max_retries:
try:
return client.mget(keys)
except redis.exceptions.ResponseError as e:
if "TRYAGAIN" in str(e):
# Wait 25ms before retrying
time.sleep(0.025)
attempt += 1
continue
raise e
raise Exception(f"Command failed after {max_retries} retries due to slot migration.")
Step 3: Resolve Infrastructure BottlenecksIf the error persists for more than a few seconds, your migration might be stalled. This often happens if a single slot contains a "hot key" or a massive O(N) data structure that takes a long time to serialize and transmit.
Increase Migration SpeedSpeed up the process by increasing the pipeline size. By default, redis-cli moves keys slowly to avoid CPU spikes. You can accelerate this by moving 100 keys per round-trip instead of one:
redis-cli --cluster reshard <ip>:<port> --cluster-pipeline 100
Force-Stable the SlotIf a migration is completely hung, you may need to manually set the slot state to stable. Only do this if you have verified the data exists on the destination or if you plan to run a fix command immediately after. On both the source and destination nodes, run:
redis-cli -h <node_ip> -p 6379 CLUSTER SETSLOT 5461 NODE <destination_node_id>
VerificationConfirm the cluster has returned to a healthy state by running the check tool:
redis-cli --cluster check 192.168.1.10:6379
Look for the confirmation: [OK] All 16384 slots covered. If you see "Nodes don't agree about configuration," run redis-cli --cluster fix to synchronize the slot maps.