Cluster.initial_master_nodes setting needs more info and future of this setting

I followed - Bootstrapping a cluster | Elasticsearch Guide [8.15] | Elastic

Below are my questions and suggestions:

1). I was asked to remove this setting once cluster is up even from data or master nodes.
Now if I need to completely shutdown cluster and bring backup, do I need this setting in any of the nodes? Imagine my order of shutting down is First data,query,master. Now all nodes are down, next Im gona bring up master first, should I have this setting or not at all, does it need explicit setting of bootstrap or it understands its a known family and can come up based on discovery.seed_hosts value cluster restarts. Because bootstrap could be with data or withoutdata based on DB softwares. Kindly suggest what will happen in this case and what should be the setting.

2). Suggestion :slight_smile: We use salt-stack or ansible lets consider any configuration tool, and we maintain the state of the yaml files from git. We would like to have one setting in server and after nodes joined the same setting in server and the same follows in git, now situation is have ver1 in server and git, and once up, make changes to settings in server as ver2 and ver2 for git. This introduces dual execution of yaml files before up and after up. If there is a setting that is done once and forget, it will be easy from operations and manual error handling point of view.

Not sure if I have clearly explained my query or suggestion, kindly let me know incase of any questions here.

No. This is covered in the docs you link:

It should not be set for master-ineligible nodes, master-eligible nodes joining an existing cluster, or nodes which are restarting.

Most such config tools aren't really designed to support a stateful clustered application like Elasticsearch. I mean they kind of work ok but they don't deal with corner cases like cluster bootstrapping very well.

Thanks @DavidTurner that answers on first part, although I saw nodes which are restarting in doc. There is a difference between nodes restarting within the cluster which means its meta state stays somewhere in the cluster group. If the doc also has > It should not be set for master-ineligible nodes, master-eligible nodes joining an existing cluster, or nodes which are restarting even incase of complete cluster shutdown and startup post nodes were joined earlier. Would clear it for me. But your call to append this in your doc. But such statements clarifies a lot like me.

That's not correct, and the point is that there isn't a difference. The docs apply to any node restart. I opened Mention full-cluster restart in `initial_master_node` docs by DaveCTurner · Pull Request #112986 · elastic/elasticsearch · GitHub to spell this out.

1 Like