# What's the downside of making all data nodes master eligible

**URL:** <https://discuss.elastic.co/t/whats-the-downside-of-making-all-data-nodes-master-eligible/175495>\
**Category:** Elasticsearch\
**Created:** [April 5, 2019, 12:07am UTC](https://discuss.elastic.co/t/whats-the-downside-of-making-all-data-nodes-master-eligible/175495 "2019-04-05T00:07:52Z")\
**Posts on this page:** 1\
**Showing post:** 1

<div class="post-metadata">

**Author:** ![riches](https://avatars.discourse-cdn.com/v4/letter/r/ac91a4/32.png) [@riches](https://discuss.elastic.co/u/riches)\
**Post date:** [April 5, 2019, 12:07am UTC](https://discuss.elastic.co/t/whats-the-downside-of-making-all-data-nodes-master-eligible/175495/1 "2019-04-05T00:07:53Z")

</div>

I understand it's recommended to configure 3 dedicated master nodes. I'm curious what's the downside of making all N, N \> 3, nodes both data nodes and master eligible in practice? One I can think of is that the elected master might be a loaded data node, which can become unresponsive

Would master election process take much longer when current master is down? Does Zen and ESv7 discovery module behave the same in this sense?

If any cluster state update needs to be replicated across all (or `minimum_master_nodes`) master eligible nodes before sending to non-master eligible nodes, does this configuration make cluster state update much slower in practice for bigger clusters, for example, N == 12 or 36 or 50+? Again, is ESv7 discovery module going to perform better than Zen?

If this configuration becomes really bad when N \> x, what is the X here?

---

_[View the full topic](https://discuss.elastic.co/t/whats-the-downside-of-making-all-data-nodes-master-eligible/175495)._