Redis Cluster stops accepting queries when hash slots are not assigned to nodes. This error indicates the cluster is in a partially degraded state where one or more of the 16384 hash slots lack node coverage, preventing normal operations.
Redis Cluster divides the keyspace into 16384 hash slots and distributes them across nodes. By default, when a node detects that at least one hash slot is uncovered (no node is assigned to serve it), the entire cluster enters CLUSTERDOWN mode and rejects all client requests with this error. This is a safety mechanism: rather than allow writes to a degraded cluster that might cause data inconsistency, Redis stops all operations until the cluster state is resolved. A hash slot can become unserved when a master node fails and no replica takes over, when cluster resharding is interrupted, or when nodes fail to properly join the cluster during initialization.
First, verify your cluster status and see which slots are missing:
redis-cli -c cluster nodes
redis-cli -c cluster slots
redis-cli -c cluster infoLook for nodes marked as "fail" or "disconnected". The cluster slots output should show all 16384 slots assigned. If slots are missing or nodes report "unknown" slots, that's your problem.
If you're not actually running Redis in cluster mode and this error appeared unexpectedly, disable clustering:
1. Edit your Redis config file (usually /etc/redis/redis.conf or /etc/redis/redis-cluster.conf):
cluster-enabled no2. Restart Redis:
redis-cli shutdown
# then restart redis-serverThis resolves the error if you're not intentionally using cluster mode.
If a node is disconnected but still running, force it back into the cluster:
# From the disconnected node, explicitly rejoin the cluster
redis-cli CLUSTER MEET {master-ip} {master-port}Replace {master-ip} and {master-port} with a known working cluster node. The node should re-synchronize slot assignments.
Then verify slot coverage:
redis-cli CLUSTER SLOTS | grep -c "^[0-9]"All 16384 slots should eventually be assigned.
If a resharding operation was interrupted, slots might be stuck. Check:
redis-cli CLUSTER NODES | grep -i "migrating|importing"If slots are stuck, use redis-cli to stabilize them:
# For each stuck slot number (e.g., 5000)
redis-cli CLUSTER SETSLOT 5000 STABLE
# Or on the target node during migration
redis-cli CLUSTER SETSLOT 5000 STABLEAfter stabilizing, verify with CLUSTER SLOTS again.
Redis provides an automated repair tool:
redis-cli --cluster fix {any-node-ip}:{port}This command connects to the cluster and attempts to:
- Detect nodes that are missing or in a bad state
- Reassign unserved slots to available nodes
- Correct inconsistent slot assignments
Example:
redis-cli --cluster fix 192.168.1.10:6379Review the output carefully before confirming any changes.
If more than one master crashed and no replicas exist, you may need to rebuild:
1. Ensure all nodes are running and accessible
2. Flush data if acceptable:
redis-cli FLUSHALL3. Recreate the cluster with proper slot distribution:
redis-cli --cluster create \
192.168.1.10:6379 \
192.168.1.11:6379 \
192.168.1.12:6379 \
--cluster-replicas 1Use --cluster-replicas 1 to ensure each master has one replica for failover protection.
Preventing Future Occurrences:
Always deploy Redis Cluster with adequate replication (at least 1 replica per master). Use your orchestration platform's health checks to automatically remove failed nodes and promote replicas. Monitor cluster state regularly with CLUSTER INFO and alert on slot coverage gaps.
Cluster-Require-Full-Coverage Setting:
You can set cluster-require-full-coverage no in redis.conf to allow the cluster to accept writes even with unserved slots. However, this masks the underlying problem and risks data inconsistency. Only use this as a temporary workaround while investigating the root cause—always fix slot coverage properly.
Application-Side Handling:
Use Redis client libraries that support automatic cluster slot redirection and connection pooling. Libraries like redis-py, node-redis, and go-redis automatically retry with the correct node when MOVED or ASK redirects are received, but they cannot retry CLUSTERDOWN errors. Your application should implement retry logic with exponential backoff when receiving CLUSTERDOWN.
ERR fsync error
How to fix "ERR fsync error" in Redis
CLUSTERDOWN The cluster is down
How to fix 'CLUSTERDOWN The cluster is down' in Redis
ERR Job for redis-server.service failed because a timeout was exceeded
Job for redis-server.service failed because a timeout was exceeded
ERR Unbalanced XREAD list of streams
How to fix "ERR Unbalanced XREAD list" in Redis
ERR syntax error
How to fix "ERR syntax error" in Redis