Two primaries
Below three, no majority exists, so failover cannot happen
- primaries
- 2
- replicas-per-primary
- 1
Redis Cluster Config Generator
Generate the cluster-mode settings and the redis-cli command that creates the cluster. The failure that costs the most time is the bus port: nodes gossip on the client port plus 10000, and opening only the client port produces a cluster where every node thinks the others are down.
redis-cluster.conf
updates as you typeExamples
Worked setups you can load into the form above. Each one is a decision the generator makes differently, and the reason it makes it.
No replicas
Losing one primary stops the whole cluster under the default setting
- primaries
- 3
- replicas-per-primary
- 0
Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Opening the client port and not the bus port
Nodes gossip on the client port plus 10000. Without it every node believes the others are down while clients connect normally.
Instead:Open both between all nodes.
Running fewer than three primaries
Failover needs a majority of primaries, which cannot exist below three.
Instead:Run three, even if one would hold the data.
Copying nodes.conf between nodes
It is written by Redis and carries the node's own id and its view of the cluster. Two nodes with the same id will not form a cluster.
Instead:Let each node create its own.
Leaving a database index in the connection string
Cluster mode supports database 0 only, and SELECT fails on anything else.
Instead:Remove the index from every connection URL.
What changes when you turn cluster mode on
Cluster mode is not a transparent scale-out. Several things that worked before stop working, and they fail in ways that point at the application rather than at the cluster.
Three primaries is the minimum, whatever the data size
Failover requires a majority of primaries to agree a node is down, which is impossible below three. If one node would hold all the data, that is fine: run three anyway, or use a single instance with replicas and Sentinel.
The bus port is a separate firewall rule
Nodes gossip on the client port plus 10000. Open the client port and not the bus port and clients connect to every node perfectly well while the nodes all believe each other are down. The symptom looks like a network problem inside the cluster, because it is one.
Only database 0 exists
SELECT on any other index fails. A connection URL with a database number in it cannot work against a cluster, and the error appears at connect time rather than where the number was configured.
Multi-key commands need the keys in one slot
MGET, MSET and anything else touching several keys fails with CROSSSLOT unless every key hashes to the same slot. A hash tag, the part in braces, is what forces that, and choosing the tag badly concentrates the keyspace on one node.
cluster-require-full-coverage is a real choice
On, which is the default, the whole cluster stops serving if any slot is unassigned: consistency over availability. Off, it serves the slots it has. Neither is wrong, and defaulting into one without deciding usually is.
Related redis tools
Redis CLUSTER NODES Parser Read the topology, and find the gap Redis Cluster Sizing Only 60% of each node is usable Redis Config File Generator A redis.conf with the reasons in it Redis Maxmemory Config Generator The limit, and the headroom it needs Redis Persistence Config Generator How much you can afford to lose Redis TLS Config Generator Encrypted, and the old port actually closed
All 53 redis tools