Keys in different slots
A multi-key command that fails with CROSSSLOT once sharded
MGET user:1:name user:2:email
Paste commands, one per line. Everything here works on a single instance. The point is what stops working the day the data is sharded, which is usually long after the code was written and always at the worst moment.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Check. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
A multi-key command that fails with CROSSSLOT once sharded
MGET user:1:name user:2:email
The keys share a slot, so this one works on a cluster
MGET user:{42}:name user:{42}:emailThese are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
On a single instance every key is in the same place. The failure appears only after sharding.
Instead:Hash-tag keys that are read together.
Cluster mode has only database 0 and SELECT fails on anything else.
Instead:Remove the index and use key prefixes.
Each node knows only its own slots, so the answer is a fraction.
Instead:Query every primary and combine.
Routing uses the declared KEYS. A key built in the body is invisible to it.
Instead:Pass every key through KEYS.
Cluster mode is not a transparent scale-out. Several things that worked before stop working, and they fail in ways that point at your application rather than at the cluster.
MGET, MSET, SUNION, ZUNIONSTORE, RENAME and the rest fail with CROSSSLOT unless the keys share a slot. This works on a single instance, and on a cluster where the keys happen to collide, so it can pass every test you have and fail in production. A shared hash tag is what makes it reliable.
SELECT on any other index fails. A connection URL carrying a database number cannot work at all, and the error surfaces at connect time rather than where the number was configured.
Each node knows only its own slots. Code that runs one of these against a single node and treats the answer as the keyspace silently sees a fraction of it, and the fraction changes as slots move.
Every key touched between MULTI and EXEC must share a slot, and the failure arrives at EXEC rather than at the command that introduced the second slot. A Lua script is routed by its declared KEYS, so a key built inside the script body is invisible to routing and the script runs on a node that may not own it.
An ordinary PUBLISH propagates across the whole cluster bus, so it reaches every subscriber on every node. That is convenient and it means pub/sub throughput does not improve as you add shards. SPUBLISH and SSUBSCRIBE, added in Redis 7.0, are routed by slot instead.