vote-only cluster instances

[mrkamel]

hi,

currently, if you want to install a 3 node cluster (node A, B, C) where each node runs 2 redis instances (usually a master and a slave, but not of each other), you can end up unavailable. Scenario: 1 step) node A becomes unavailable 2) failover is triggered, such that (assume) now B runs two masters 3) node A gets available again 4) one day later B becomes unavailable, such that the cluster looses 2 masters and can no longer do failovers, because only masters can vote - and there is only 1 remaining available master in the cluster.

I know, by design, currently only masters can participate in voting. However, it would be great if one could, for each instance, configure whether or not an instance is allowed to vote and to set-up vote-only cluster instances, because it fixes the 3 nodes with 2 instances per node set-up, because you could simply run 2 instances on every node (ie. non-voters) plus a vote-only instance.

[indeyets]

3 years later is still sounds like a good idea

[yossigo]

This is indeed an issue with the current cluster design.

Adding quorum (vote-only) nodes would be a great enhancement to Redis Cluster, as it will also provide more deployment flexibility. What you're proposing here goes beyond that as it also requires to consider non-voting masters. This is definitely high on the cluster roadmap.

[indeyets]

I think that, putting it in the most simple terms, this issue is about separating "voting" from "data serving".

Similar to how redis-sentinel is separate from actual redis instances or how "coordinators" are separate in undermoon cluster

[The-TT-Hacker]

I think elasticsearch does this, nodes can be assigned a number of different roles including "master", "voting_only " and "data" so you can have master nodes which only participate in voting. The voting only role just prevents a master node from being elected.

Having this in Redis would be quite useful in my situation where we deploy on premises and customers don't want to stand up 3 expensive servers to have redundancy. They could just have 2 with a cheaper machine to participate in voting and doesn't host any data.

For now we can probably just run sentinals on all 3 machines and redis nodes on the 2 powerful machines, but it would be nice to be able to do this with a redis cluster.

https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html

[simonasr]

almost 6 years later it still sounds like a good idea 🙏🏻 🤞🏻 🥺

[oranagra]

FYI, maybe #10875 aims to handle it (also aims for unsharded clusters to replace sentinel deployments, so it needs voting replicas).
Anyway, if you're interested you can validate that there.

[simonasr]

Oh, thanks @oranagra for pointing this out! "Failover Coordinator/Topology Director logic" sounds great! 🚀