# Big/small number of master nodes - downsides/advantages

**URL:** <https://discuss.elastic.co/t/big-small-number-of-master-nodes-downsides-advantages/5941>\
**Category:** Elasticsearch\
**Created:** [November 22, 2011, 2:48pm UTC](https://discuss.elastic.co/t/big-small-number-of-master-nodes-downsides-advantages/5941 "2011-11-22T14:48:01Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Michal\_Wegorek](https://avatars.discourse-cdn.com/v4/letter/m/e274bd/32.png) [@Michal\_Wegorek](https://discuss.elastic.co/u/Michal_Wegorek)\
**Post date:** [November 22, 2011, 2:48pm UTC](https://discuss.elastic.co/t/big-small-number-of-master-nodes-downsides-advantages/5941/1 "2011-11-22T14:48:01Z")

</div>

There is a config option allowing to set the number of master nodes in  
ES installation:

- discovery.zen.minimum\_master\_nodes

Q1) Lets say I have N nodes in total in the system. What are the  
advantages/disadvantages of having the number of master nodes set to  
1, N/2, N

- I suspect master node is keeping the copy of all indices (contrary  
to slave node) in the cluster, so is it just a matter of space being  
used?

Q2) If minimum\_master\_nodes is set to M, and there are N (N \< M) nodes  
alive case some of them went down, will ES refuse to serve index/  
search requests?

Q3) Does master node need more memory than slave node, if simplified,  
can we say the number of memory needed is proportional to size of  
indices stored in local space? Example:  
Lets say there is 1 index in 5 shards in the system:

- one of slaves is keeping shard1 and shard2 and needs 1G mem
- one of masters is keeping shard[1-5], will it need aprox. 2.5G?

Thanks,  
Michal.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 6, 2017, 3:47am UTC](https://discuss.elastic.co/t/big-small-number-of-master-nodes-downsides-advantages/5941/2 "2017-07-06T03:47:52Z")

</div>

Closed on July 6, 2017, 3:47am UTC