Multi-key command cannot be atomically executed during cluster resharding
Production Risk
Medium — the command is rejected and must be retried; risk of silent data loss if not handled.
Returned by Redis Cluster when a multi-key command spans keys that hash to different slots, or when the cluster is in the middle of a resharding and cannot guarantee atomic execution across the involved slots.
- 1Keys in a multi-key command (e.g., MSET, MGET, SUNION) hash to different cluster slots.
- 2A cluster resharding/slot migration is in progress for one of the involved slots.
- 3The client is using multi-key operations without hash tags to co-locate keys on the same slot.
A client issues MSET with keys that land on different cluster nodes while a slot migration is underway.
# Keys hash to different slots during resharding MSET key1 "value1" key2 "value2"
expected output
(error) TRYAGAIN Multiple keys request during rehashing of slot
Fix 1
Use hash tags to co-locate keys on the same slot
WHEN You control the key naming scheme
# Use {tag} to force keys to the same slot
MSET {user:1}:name "Alice" {user:1}:email "alice@example.com"Why this works
Redis Cluster hashes only the part inside {} when computing the slot, so both keys land on the same node.
Fix 2
Retry after a short delay
WHEN Resharding is temporary and keys are intentionally on separate slots
# Pseudo-code: retry with exponential backoff
for attempt in range(3):
try:
redis.mset({"key1": "v1", "key2": "v2"})
break
except ResponseError as e:
if "TRYAGAIN" in str(e):
time.sleep(0.1 * (2 ** attempt))Why this works
TRYAGAIN is transient during slot migration; retrying after the migration window completes will succeed.
Fix 3
Split into per-key commands
WHEN Keys cannot be co-located and the operation does not need to be atomic
# Execute individual commands instead of multi-key SET key1 "value1" SET key2 "value2"
Why this works
Single-key commands always route to the correct node without cross-slot issues.
✕ Silently ignore TRYAGAIN and assume success
The write was not performed; ignoring it causes silent data loss.
✕ Retry in a tight loop without backoff
A tight retry loop during resharding can overwhelm the cluster; use exponential backoff.
Redis Cluster GA; TRYAGAIN error introduced for cross-slot and resharding scenarios.
Cluster improvements reduce resharding downtime but TRYAGAIN can still occur during slot migration.
Redis Cluster specification — cross-slot and resharding errors
Content generated with AI assistance and reviewed for accuracy. Found an error? hello@errcodes.dev