Both CLUSTER FAILOVER and CLUSTER FAILOVER FORCE could not complete successfully if master doesn't serve any slots.
Slave log contains:
13692:S 13 Jul 21:00:22.236 # Forced failover user request accepted.
13692:S 13 Jul 21:00:27.301 # Manual failover timed out.
Master log contains:
13672:M 13 Jul 20:54:43.291 # Manual failover requested by slave ac491ffac3900642aebc27e388ebe241bb0cdc54.
13672:M 13 Jul 20:54:48.390 # Manual failover timed out.
CLUSTER FAILOVER TAKEOVER completes successfully.
Comment From: funny-falcon
Is there any update on this?
Comment From: madolson
Sure, the documented behavior is that we don't failover if:
/* Pre conditions to run the function, that must be met both in case
* of an automatic or manual failover:
* 1) We are a slave.
* 2) Our master is flagged as FAIL, or this is a manual failover.
* 3) We don't have the no failover configuration set, and this is
* not a manual failover.
* 4) It is serving slots. */
So, no slots = no failover. So, I suppose the real question is why you are looking to do a failover when you aren't serving any slots. I do vaguely remember you also opened an issue where you wanted to fix the cluster topology and not allow migrations. There are a lot of assumptions in Redis cluster that are pinned on the fact that primaries must have replicas, so we might need to deep dive through quite a bit of code to make sure this works.
Comment From: madolson
https://github.com/redis/redis/issues/8948 Related
Comment From: PingXie
Re - no slots = no failover
@madolson this check seems to be too conservative to me. I think it can be safely removed and it doesn't change the design premise that only primaries with slots can participate in new primary elections. What do you think? Happy to submit a PR for your review if this sounds reasonable to you.