How to fix the Redis CROSSSLOT error
In a cluster, this means a single multi-key command touched keys that live on different slots. Forcing those keys into the same slot resolves it. Jump to your situation below or work through the methods in order.
In a cluster, this means a single multi-key command touched keys that live on different slots. Forcing those keys into the same slot resolves it. Jump to your situation below or work through the methods in order.
The Redis CROSSSLOT Keys in request don't hash to the same slot error happens in a Redis Cluster when a single multi-key command (such as MGET, MSET, a transaction, or a Lua script) references keys that map to different hash slots. Cluster commands that operate on multiple keys require all of those keys to live in the same slot, because a single command cannot span nodes. The fix is to make the related keys hash to one slot using a hash tag: wrap the common part of the key in braces, for example {user100}:profile and {user100}:orders, so Redis hashes only the bracketed portion and places both keys together. Alternatively, split the operation into per-key commands, or group keys by slot. Designing keys with hash tags from the start avoids the error.
In a cluster, each key hashes to one of 16384 slots, and each slot lives on one node. A multi-key command runs on a single node, so it requires every key it touches to be in the same slot. CROSSSLOT means the keys you passed are scattered across different slots.
Redis cannot run one command across nodes, so it refuses rather than silently splitting it. The cure is to make the related keys share a slot using a hash tag, which forces Redis to hash only the tagged part, or to break the work into separate commands that each touch one slot.
“CROSSSLOT is a cluster rule: a single multi-key command has to stay on one node, so all its keys must share a slot. The clean fix is hash tags, you wrap the common part in braces, like {user100}:profile and {user100}:orders, and Redis hashes only that bit, so both keys land together and MGET, MSET, transactions, scripts all just work. If you cannot retag, split the operation into per-key commands. Honestly, designing keys with hash tags up front saves a lot of pain.”
{user100}:profile
{user100}:ordersCLUSTER KEYSLOT key if needed.CROSSSLOT means a multi-key command spanned different cluster slots. Use a hash tag, wrap the shared part of related keys in braces like {user100}, so they hash to the same slot and multi-key commands work. Otherwise split the operation into per-key commands grouped by slot.
If keys with the same hash tag still report CROSSSLOT, the braces may be malformed (an empty {} or text outside a single tag pair changes hashing); verify with CLUSTER KEYSLOT that both keys return the same slot number. You can also submit your error to us for a tailored fix.