🚨 Redis Error Guide: 'TRYAGAIN Multiple keys request during rehashing of slot' — Fix Cluster Resharding

Overview

In a Redis Cluster, a multi-key command (or a transaction/Lua script touching several keys in one slot) can be rejected while that slot is being migrated between nodes. Redis returns:

TRYAGAIN Multiple keys request during rehashing of slot

This is not a fatal error and not a redirection like MOVED/ASK. It means: the keys you asked for live in the same slot, but some of them have already been migrated to the target node and some have not, so the source node cannot atomically serve the command right now. The correct response is to wait briefly and retry.

Symptoms

• Sporadic TRYAGAIN responses that appear only during CLUSTER resharding, node addition, or rebalancing — and vanish once migration completes.
• Only multi-key operations fail: MGET, MSET, SUNIONSTORE, SINTERSTORE, COPY, SMOVE, Lua scripts with several KEYS, and MULTI/EXEC blocks.
• Single-key commands to the same keys succeed (they follow ASK redirection cleanly).
• The error is intermittent and self-heals; retries usually succeed within milliseconds to seconds.
• Load spikes or client errors correlate exactly with a resharding window.

Common Root Causes

• Active slot migration — a slot is in the MIGRATING/IMPORTING state and its keys are being moved one batch at a time; a multi-key command spanning already-moved and not-yet-moved keys can’t be served atomically.
• Multi-key command over a migrating slot — the command is legal (all keys hash to one slot via hash tags) but the timing overlaps migration.
• Client that doesn’t retry TRYAGAIN — many naive clients treat it as a hard error instead of the transient, retryable condition it is.
• Long-running or large resharding — moving big keys or many slots widens the window in which TRYAGAIN can occur.
• Hot multi-key access to a slot being rebalanced — high QPS on the exact slot in flight raises the odds of hitting the in-between state.

Diagnostic Workflow

First confirm a migration is actually in progress — TRYAGAIN should only appear during one:

# Overall cluster health and whether a migration is underway
redis-cli -c CLUSTER INFO
redis-cli -c CLUSTER NODES | grep -E 'migrating|importing'

CLUSTER NODES marks slots being moved with [slot->-<node>] (migrating, on the source) and [slot-<-<node>] (importing, on the target). Find the slot for the keys that failed:

# Which slot do the failing keys hash to?
redis-cli -c CLUSTER KEYSLOT app:{user42}:profile
redis-cli -c CLUSTER KEYSLOT app:{user42}:sessions
# Same number for all keys = correctly co-located via hash tag {user42}

Inspect that slot’s migration state directly on the owning node:

# Count keys still in the slot on the source node
redis-cli -c CLUSTER COUNTKEYSINSLOT 5798
# See the slot's owner and any migrating/importing marker
redis-cli -c CLUSTER SLOTS
redis-cli -c CLUSTER SHARDS

Confirm the error is transient by retrying the exact command after a short pause:

# From the app node, retry the multi-key command; it should succeed once
# the slot's keys have all landed on the target node.
redis-cli -c MGET app:{user42}:profile app:{user42}:sessions

Check whether resharding is still moving (key count in the slot should trend to zero on the source):

watch -n1 'redis-cli -c CLUSTER COUNTKEYSINSLOT 5798'

Example Root Cause Analysis

A checkout service started logging bursts of errors during a planned cluster scale-out from 3 to 4 primaries. The failing operation was an MGET of two keys, cart:{order991}:items and cart:{order991}:totals, correctly hash-tagged to co-locate in one slot.

CLUSTER KEYSLOT confirmed both keys mapped to slot 9412. CLUSTER NODES on the source primary showed:

... myself,master ... [9412->-a1b2c3...] connected

The slot was mid-migration to the new node. During the move, some keys in slot 9412 had already been transferred and some had not, so the source could not serve the two-key MGET atomically and returned TRYAGAIN. The application’s Redis client logged it as a hard failure instead of retrying.

Two facts confirmed the diagnosis: single-key GET on either key succeeded (following ASK), and CLUSTER COUNTKEYSINSLOT 9412 was steadily dropping toward zero. Once migration finished, the errors stopped entirely.

The fix was on the client side: treat TRYAGAIN as retryable with a short exponential backoff, capped at a few attempts:

# Pseudocode retry policy for TRYAGAIN
for attempt in 1..5:
    try: return client.mget(keys)
    except RedisError as e:
        if e.startswith("TRYAGAIN"):
            sleep(0.02 * 2**attempt)   # 20ms, 40ms, 80ms, ...
            continue
        raise
raise LastError

No cluster change was needed — the resharding was healthy; only the client’s error handling was wrong.

Prevention Best Practices

• Retry TRYAGAIN with capped exponential backoff — it is explicitly a transient, retryable condition, not a failure. Most mature cluster clients do this automatically; verify yours does.
• Reshard during low-traffic windows so fewer multi-key commands hit slots in flight, and move slots in smaller batches.
• Keep multi-key operations rare and small — the fewer keys a command spans, the smaller the window for the in-between state.
• Use hash tags deliberately so co-located keys stay in one slot (avoiding CROSSSLOT), but understand that co-location is exactly what exposes you to TRYAGAIN during migration.
• Monitor CLUSTER NODES/CLUSTER INFO during rebalancing and alert on prolonged migration states.
• Prefer online, incremental resharding (redis-cli --cluster reshard) and let it finish rather than pausing mid-move.
• Don’t confuse TRYAGAIN with MOVED/ASK — the latter are redirections you follow to a node; TRYAGAIN is a wait-and-retry on the same request.

Quick Command Reference

redis-cli -c CLUSTER INFO                       # cluster_state, slots assigned/ok
redis-cli -c CLUSTER NODES | grep -E 'migrating|importing'
redis-cli -c CLUSTER KEYSLOT app:{user42}:profile   # slot for a key
redis-cli -c CLUSTER COUNTKEYSINSLOT 5798       # keys remaining in a slot
redis-cli -c CLUSTER SLOTS                      # slot -> node ownership
redis-cli -c CLUSTER SHARDS                     # shard topology (Redis 7+)
redis-cli --cluster check 127.0.0.1:6379        # consistency of slot coverage
redis-cli --cluster reshard 127.0.0.1:6379      # online slot migration
watch -n1 'redis-cli -c CLUSTER COUNTKEYSINSLOT 5798'   # watch migration drain

Conclusion

TRYAGAIN Multiple keys request during rehashing of slot is a healthy sign of an in-progress cluster resharding, not a bug: a multi-key command hit a slot whose keys were partway through migration, so the source node deferred rather than serving a non-atomic result. The right fix lives almost entirely in the client — retry with a short, capped backoff — because the error self-heals the instant the slot finishes moving. Reserve larger structural changes (smaller resharding batches, off-peak windows, fewer multi-key commands) for reducing how often you see it, and never confuse this retryable wait with the MOVED/ASK redirections that point you to a different node.