# Cluster bootstrapping fundamentals and using cnames for cluster.initial\_master\_nodes **URL:** \ **Category:** Elasticsearch\ **Created:** [June 1, 2019, 12:01am UTC](https://discuss.elastic.co/t/cluster-bootstrapping-fundamentals-and-using-cnames-for-cluster-initial-master-nodes/183797 "2019-06-01T00:01:00Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![zorah](https://avatars.discourse-cdn.com/v4/letter/z/c2a13f/32.png) [@zorah](https://discuss.elastic.co/u/zorah)\ **Post date:** [June 1, 2019, 12:01am UTC](https://discuss.elastic.co/t/cluster-bootstrapping-fundamentals-and-using-cnames-for-cluster-initial-master-nodes/183797/1 "2019-06-01T00:01:00Z")
A few questions about the fundamentals of the use of `cluster.initial_master_nodes` and cluster bootstrapping and master election. The documentation mentions that the `cluster.initial_master_nodes` setting is used for initial cluster bootstrapping and master election and then is otherwise ignored moving forward. However, in the case of a cluster restart or start/stop, wouldn't this bootstrapping process occur again? In other words is the bootstrapping process something could happen one or more times during the life time of my cluster for any reason, requiring reuse of the `cluster.initial_master_nodes` settings? For context, I'm working on setting up an ES 7 cluster on GCE and wanted to use a list of cnames for the `cluster.initial_master_nodes` setting in the `elasticsearch.yml`. The `node.name` property is set to the A record name for the instance and, as you'd expect, I ran into [the error that the documentation said I would get](https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-discovery-bootstrap-cluster.html#modules-discovery-bootstrap-cluster-fqdns). For now, I set the `cluster.initial_master_nodes` to be the explicit A record names of three of our instances and things are working. Why do the `cluster.initial_master_nodes` and `node.name`s need to match? More importantly, given that they do need to match, what is the recommended way to manage master nodes rotating in and out? My intent was that if the individual instances that are designated as masters fail and are replaced with instances of a different name, we can just point the cname to a new instance without requiring a configuration update. I suspect I have some misunderstanding of how this setting is used and/or of some Elasticsearch fundamentals. If `cluster.initial_master_nodes` is truly only needed exactly once for a cluster, that makes my concern about the master management problem a lot easier 🙂 Thanks in advance! ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [June 1, 2019, 8:58am UTC](https://discuss.elastic.co/t/cluster-bootstrapping-fundamentals-and-using-cnames-for-cluster-initial-master-nodes/183797/2 "2019-06-01T08:58:24Z")
> [@zorah](#): > > However, in the case of a cluster restart or start/stop, wouldn't this bootstrapping process occur again? No. After the first election, everything needed for subsequent elections is kept on disk and so it persists across restarts. From [the manual](https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-discovery-bootstrap-cluster.html): > ... nodes that have already joined a cluster store this information in their data folder ... > [@zorah](#): > > Why do the `cluster.initial_master_nodes` and `node.name` s need to match? `cluster.initial_master_nodes` gives the names of the nodes whose votes count in the first election. The cluster waits until it finds these nodes before holding the first election. If it doesn't match your node names then it will be waiting indefinitely. > [@zorah](#): > > what is the recommended way to manage master nodes rotating in and out? This is [covered in the manual at some length](https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-discovery-adding-removing-nodes.html) and has nothing to do with `cluster.initial_master_nodes`. After the first election, the `cluster.initial_master_nodes` setting is ignored. > [@zorah](#): > > If `cluster.initial_master_nodes` is truly only needed exactly once for a cluster, that makes my concern about the master management problem a lot easier It truly is, and I hope that resolves your concerns. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [June 29, 2019, 8:58am UTC](https://discuss.elastic.co/t/cluster-bootstrapping-fundamentals-and-using-cnames-for-cluster-initial-master-nodes/183797/3 "2019-06-29T08:58:30Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.