How about Force change cluster's elected master node

When i see the issues:



When talk about force change cluster's elected master node, if there is a master leave but cluster settings not changed, what if changed the cluster block level into METADATA_WRITE? not BLOCK WRITE.
when only BLOCK METADATA, I wonder whether a data node can continuously write (not block when new master elected) when only change the leader without metadata changed.

The two linked issues are about cases where a master election took much longer than expected, causing indexing requests to be rejected. Master elections should not take this long: normally it's a few seconds in 6.x and earlier, and a few hundred milliseconds in 7.x, and it's best for indexing to wait for the new master to be elected. In both cases it seems that there were infrastructural issues leading to an excessively long election, and everything worked much better once those issues were addressed. There's been another change in Elasticsearch recently that improves the election speed under certain network partitions too.

It is true that indexing itself does not directly require the involvement of a master node and can therefore theoretically carry on if the master node fails. However, lots of other things stop working with no master, so it's simpler to block indexing until the new master is elected.

1 Like

Thanks for replying this question. I have seen these PR39629 and PR31547, It reduce the cluster blocking time when new master publish the new cluster state under certain kinds of partition.

I wonder how do you reduce the cluster blocking time when handle a leader must step down as it need to reboot for maintenance not network partitions.
I checked some source code, when the leader want to stop itself, it would request to the next leader candidate and then start a new master election. this is what you talk about:

These time cost in elections and publish new cluster states.

I don't understand the question. If the leader is shut down then a new leader is elected very quickly already: a few seconds in 6.x and a few hundred milliseconds in 7.x.

1 Like

When a leader shut down for maintenance, all the index requests would blocked util the new leader published a new cluster_state. i wonder is it any solutions to handle it, like only BLOCK METADATA which make data nodes can continuously write. but as you said:

so i wonder is there any other solutions?

I'm still not understanding the problem that needs solving. When you shut down the leader in a 7.x cluster you should see a brief pause in indexing (a few hundred milliseconds at most, normally much less). Is this a problem? Why?

1 Like

Sorry, I misunderstand the block cluster as a problem.

It is a great promotion from seconds to milliseconds,
Thanks for your answer!:+1: