Would a SIGTERM on master handle automatic exclusion from voting configuration
No, and this is deliberate. Most of the time when you shut a master-eligible node down you want to keep it in the voting configuration.
As long as there are at least three master-eligible nodes in the cluster, as a general rule it is best to remove nodes one-at-a-time, allowing enough time for the cluster to automatically adjust the voting configuration and adapt the fault tolerance level to the new set of nodes.
I was referring to this part. If it would be better if nodes joining the cluster would have been auto-included to the voting configuration
This is what Elasticsearch does today.
What I meant was since the documentation say it's better to wait while shutting down nodes one by one for voting configuration to auto adjust wouldn't it just be better to have SIGTERM do that and instead rely on nodes joining to get auto included
Even if nodes were removed on a SIGTERM you'd still have to remove nodes one-at-a-time and wait for the voting configuration to adjust, to handle cases where you sent a SIGTERM and then the process exited for some other reason (SIGKILL, OOM, etc).
Furthermore, this'd put a wait on the network into the shutdown path. Nodes that are partitioned from the master would have to wait indefinitely.
And finally, as I said above, you normally don't want to remove a node from the voting config when you shut it down.
If it helps, note that the master will remove a node from the voting config on a network disconnection (if it is appropriate to remove it at all, which it normally isn't). This handles the SIGKILL and OutOfMemoryError cases as well as the clean shutdown case. The wait-for-removal is normally very short.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.