# Influence master selection in elasticsearch **URL:** \ **Category:** Elasticsearch\ **Created:** [September 13, 2025, 12:26pm UTC](https://discuss.elastic.co/t/influence-master-selection-in-elasticsearch/381925 "2025-09-13T12:26:09Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Phoenix2](https://avatars.discourse-cdn.com/v4/letter/p/ac8455/32.png) [@Phoenix2](https://discuss.elastic.co/u/Phoenix2)\ **Post date:** [September 13, 2025, 12:26pm UTC](https://discuss.elastic.co/t/influence-master-selection-in-elasticsearch/381925/1 "2025-09-13T12:26:09Z")
How can I influence the master selection, or how does Elasticsearch select the next master node? As far as I have discovered, it is not possible to influence this, but: Currently, it is always data node 01 for me, but I would like to create a dedicated master. This master should then naturally be selected preferentially, as this is its only job. The other nodes have additional roles such as data, transform, etc. So far, when performing a rolling upgrade, I always start data nodes 1 to 6 one after the other. But Node 1 is always the master. If there is no fixed priority, why is 1 always the master? Is the master role influenced by internal ID (order of the nodes created), longest uptime, or something similar? ---
**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:** [September 13, 2025, 1:42pm UTC](https://discuss.elastic.co/t/influence-master-selection-in-elasticsearch/381925/2 "2025-09-13T13:42:34Z")
You can influence the master selection with the `master` and `voting_only` roles. ---
**Author:** ![Phoenix2](https://avatars.discourse-cdn.com/v4/letter/p/ac8455/32.png) [@Phoenix2](https://discuss.elastic.co/u/Phoenix2)\ **Post date:** [September 13, 2025, 1:52pm UTC](https://discuss.elastic.co/t/influence-master-selection-in-elasticsearch/381925/3 "2025-09-13T13:52:27Z")
I know my question was whether anything else plays a role in selecting the master. Otherwise, in my cluster, one system would not always become the master, even though three (identical) servers have the master role, which means they can also become the master. Therefore, it does not appear to be a random assignment to me. ---
**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:** [September 13, 2025, 7:12pm UTC](https://discuss.elastic.co/t/influence-master-selection-in-elasticsearch/381925/4 "2025-09-13T19:12:07Z")
It's almost always a simple race: the first node to start an election will typically win it and become the master. There may be some situations where the order of iteration in a Java `Map` matters but you can't control this yourself. Why does it matter? ---
**Author:** ![Phoenix2](https://avatars.discourse-cdn.com/v4/letter/p/ac8455/32.png) [@Phoenix2](https://discuss.elastic.co/u/Phoenix2)\ **Post date:** [September 13, 2025, 7:42pm UTC](https://discuss.elastic.co/t/influence-master-selection-in-elasticsearch/381925/5 "2025-09-13T19:42:22Z")
It matters if you create extra dedicated master server but still want to keep the master role on other servers as a backup. Since it always selects the same server as the master for me, I thought there might be another factor involved. The update/reboot sequence is always the same, which is why I suspect it has something to do with that. ---
**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:** [September 14, 2025, 11:07am UTC](https://discuss.elastic.co/t/influence-master-selection-in-elasticsearch/381925/6 "2025-09-14T11:07:07Z")
> [@Phoenix2](#): > > It matters if you create extra dedicated master server but still want to keep the master role on other servers as a backup. Sure, but why do you want a dedicated master in the first place? Put differently, if your data nodes don’t have capacity to _be_ the master, they aren’t a viable backup option either. > [@Phoenix2](#): > > The update/reboot sequence is always the same, which is why I suspect it has something to do with that. The longest-running master-eligible node is most likely to be the elected master just because that’s how the probabilities work out.