An uneven split
One primary holding most of the slots, and how far from even that is
a1b2c3d 10.0.0.1:6379@16379 myself,master - 0 0 1 connected 0-15000 e4f5a6b 10.0.0.2:6379@16379 master - 0 0 2 connected 15001-16383
Paste CLUSTER NODES output to see the slot share per primary, the deviation from an even split, and any unassigned ranges. Useful before and after a rebalance.
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 Show. 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.
One primary holding most of the slots, and how far from even that is
a1b2c3d 10.0.0.1:6379@16379 myself,master - 0 0 1 connected 0-15000 e4f5a6b 10.0.0.2:6379@16379 master - 0 0 2 connected 15001-16383
What a rebalanced cluster looks like, which is still not proof of even load
a1b2c3d 10.0.0.1:6379@16379 myself,master - 0 0 1 connected 0-8191 e4f5a6b 10.0.0.2:6379@16379 master - 0 0 2 connected 8192-16383
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Slots are not keys and not bytes. One slot can hold one small string or a hash with millions of fields, so two nodes with identical slot counts can differ by an order of magnitude.
Instead:Compare used_memory per node from INFO first, then decide whether slot movement is the right lever.
A new primary joins with zero slots and stays idle until slots are moved to it. It is not a load balancer pool.
Instead:Run redis-cli --cluster rebalance after adding, during a quiet period.
Slots are the unit of assignment, not the unit of work. Evening them out is necessary and nowhere near sufficient, which is why a rebalanced cluster can still have one node at capacity.
CRC16 distributes random key names well, and real key names are not random. A hash tag concentrates every key sharing that tag into one slot by design, so a tag used by a large tenant puts all of that tenant's data on one node. No amount of rebalancing moves it, because moving the slot moves all of it together.
One slot can hold a single small string or a hash with millions of fields. Two nodes with an identical slot count can differ by an order of magnitude in memory, and the slot count will keep looking correct throughout.
redis-cli --cluster rebalance migrates keys slot by slot while the cluster serves traffic. It is safe and it is not free: it costs network, CPU and a stream of ASK redirects during the move. Doing it during peak traffic to fix a problem that appeared during peak traffic tends to make the peak worse first.
A new primary joins with zero slots and stays idle until slots are moved to it. This surprises people who expect joining a cluster to be like joining a load balancer pool.
It counts slots. It cannot see how many keys are in each, how much memory each node uses, or where the traffic goes. The slot count is the only part of the picture visible from CLUSTER NODES, and it is the least informative part of it. Compare with used_memory per node from INFO before deciding anything.