Paste the output of CLUSTER NODES. This resolves the topology, counts slot coverage exactly, and reports the conditions that stop a cluster serving: unassigned slots, failed nodes and primaries with no replica.
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 Parse. 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.
Three primaries covering all 16,384 slots, with the replica situation called out
07c37df 10.0.0.4:6379@16379 slave e7d1eec 0 1426238317239 4 connected 67ed2db 10.0.0.2:6379@16379 master - 0 1426238316232 2 connected 5461-10922 292f8b3 10.0.0.3:6379@16379 master - 0 1426238318243 3 connected 10923-16383 e7d1eec 10.0.0.1:6379@16379 myself,master - 0 0 1 connected 0-5460
One unassigned slot, which stops the whole cluster serving
67ed2db 10.0.0.2:6379@16379 master - 0 1426238316232 2 connected 5461-10922 292f8b3 10.0.0.3:6379@16379 master - 0 1426238318243 3 connected 10924-16383 e7d1eec 10.0.0.1:6379@16379 myself,master - 0 0 1 connected 0-5460
A node a quorum agreed is down, and what that costs if it held slots
67ed2db 10.0.0.2:6379@16379 master,fail - 0 1426238316232 2 disconnected 8192-16383 e7d1eec 10.0.0.1:6379@16379 myself,master - 0 0 1 connected 0-8191
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
The node you asked carries `myself,master`, so a whole-string comparison fails on exactly one line in every output: the one describing the node you connected to.
Instead:Split the field on commas and check membership.
`[slot-<-id]` and `[slot->-id]` are migrating, not owned. Counting them makes a half-finished resharding look like a healthy cluster.
Instead:Count only bare slots and ranges, and report migration separately.
Nodes gossip on the client port plus 10000. Blocking it while allowing the client port gives a cluster where every node believes every other is down, while clients connect fine.
Instead:Open both ports between all nodes.
Each line is one node, space separated, with the slot list at the end. Most of it is self-explanatory and these three are not.
The flags field is comma separated and the node you asked carries myself alongside its real role, as myself,master. Comparing the whole field against master fails on exactly one line in every output, which is the line describing the node you connected to.
[slot-<-nodeid] means importing and [slot->-nodeid] means exporting, both during a resharding. Counting them as coverage makes a half-finished migration look like a healthy cluster. During a migration a key that has already moved answers ASK rather than MOVED, and a client must send ASKING and retry once WITHOUT updating its slot map, because the slot has not actually changed owner yet.
The endpoint is ip:port@busport, and the bus port is the client port plus 10000. Nodes gossip on it, and blocking it while allowing the client port produces a cluster where every node believes every other node is down, with clients able to connect to all of them.
With cluster-require-full-coverage set to yes, which is the default, a single unassigned slot makes the whole cluster refuse requests rather than only the affected range. That is a deliberate choice favouring consistency, and it means the difference between healthy and down can be one slot out of 16,384.
This is one node's view of the cluster, taken at one moment. Nodes disagree during a failover or a partition, so a node marked fail here may be healthy from another node's perspective. It also cannot see key distribution within slots: an even slot split says nothing about whether the load is even.