This is a question, but also an improvement suggestion at the same time.
I was wondering why redis votes only when: 1. It is a master node. 2. It is assigned to at least 1 keyslot. This means it is not possible to have a voting-only redis node.
I have discovered this issue after creating a single-shard redis cluster. (I ended up creating my own Sentinel-like program for this case)
So my question is - Why redis slaves don't vote? What is the rationale behind this design? What do you think about making slaves vote too?
Thanks.
Comment From: madolson
@myungjae1 Great question! The rational is that masters with assigned slots can, almost, always achieve consensus about who is in the quorum group and who is not. As you suggested we could have everyone that is "known" in the cluster vote, however we can have situations where old nodes are dead and we don't really know if they are alive or should include them in voting. The nice property of only having masters vote is that there is only ever one per shard, so once it's demoted we know we have another live node that is replacing it.
We are planning on iterating on this as part of our Cluster V2 project, see https://github.com/redis/redis/issues/8948, and want to build a more stable quorum group that doesn't rely on mastership. This is so that we can also apply this to non-clustered Redis configurations, exactly like what you're suggesting. Let me know if this helps!
Comment From: myungjae1
Thanks @madolson yes, your explanation definitely helps a lot. Especially good to know that there is already a plan to improve this (other things look pretty promising too!)
Just curious, is there any discussion thread or things like design doc about this "voting replicas" (or "more stable quorum")? I'd like to learn from them, if any.
Comment From: madolson
@myungjae1 Someone from AWS is thinking about taking a look here, but we haven't really started working on it yet.