Hash slot is served by a different node
Production Risk
Low, if clients are cluster-aware. High, if they are not, as it will result in command failures.
In Redis Cluster, this is not a true error but a redirection. It tells a client that the key it's trying to access belongs to a different node in the cluster. A compliant client will use this information to reconnect to the correct node.
- 1The client is not 'cluster-aware' and is connected to a random node.
- 2The cluster topology has changed (e.g., due to resharding or failover), and the client's local cache of the slot distribution is outdated.
- 3A key was accessed for the first time, and the client guessed the wrong node.
A client connects to Node A but tries to access 'mykey', which hashes to a slot owned by Node B.
# Connected to Node A GET mykey
expected output
(error) MOVED 12345 192.168.1.100:6379
Fix 1
Use a cluster-aware client library
WHEN When connecting to a Redis Cluster
// Example for node-redis
const client = createClient({
rootNodes: [{ url: "redis://192.168.1.99:6379" }],
// The 'cluster' option is implicitly enabled
});Why this works
Cluster-aware clients automatically handle MOVED redirections. They maintain a map of slots to nodes and will reissue the command to the correct node specified in the redirection message.
Fix 2
Start redis-cli with the -c flag
WHEN When using the command-line interface
redis-cli -c -p 6379
Why this works
The `-c` flag enables cluster mode in the CLI, which makes it automatically follow MOVED and ASK redirections.
✕ Hardcode connections to specific nodes for specific keys
The slot distribution can change at any time due to resharding or failover. Relying on a static map will cause your application to fail. Always use a dynamic, cluster-aware client.
Redis Cluster client-server interaction protocol
Content generated with AI assistance and reviewed for accuracy. Found an error? hello@errcodes.dev