Two primaries
Below three, no majority exists, so failover cannot happen
- primaries
- 2
- replicas-per-primary
- 1
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.
Worked setups you can load into the form above. Each one is a decision the generator makes differently, and the reason it makes it.
Below three, no majority exists, so failover cannot happen
Losing one primary stops the whole cluster under the default setting
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
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.
Failover needs a majority of primaries, which cannot exist below three.
Instead:Run three, even if one would hold the data.
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.
Cluster mode supports database 0 only, and SELECT fails on anything else.
Instead:Remove the index from every connection URL.
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.
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.
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.
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.
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.
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.