# Best solution for this case

**URL:** <https://discuss.elastic.co/t/best-solution-for-this-case/287900>\
**Category:** Elasticsearch\
**Created:** [October 28, 2021, 10:25am UTC](https://discuss.elastic.co/t/best-solution-for-this-case/287900 "2021-10-28T10:25:43Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![auto\_reply\_007](https://avatars.discourse-cdn.com/v4/letter/a/97f17d/32.png) [@auto\_reply\_007](https://discuss.elastic.co/u/auto_reply_007)\
**Post date:** [October 28, 2021, 10:25am UTC](https://discuss.elastic.co/t/best-solution-for-this-case/287900/1 "2021-10-28T10:25:43Z")

</div>

I have a cluster consisting of 4 data and 1 master node  
each node has:  
cpu: 4  
ram: 16  
and we have 1 largest index of 215 gigabytes (1 primary and 1 replica shard)  
on peak days, this index is very heavily loaded (we use aggregation queries, since the index is used to store and send notifications to users), which negatively affects the operation of the entire cluster  
the developers propose to allocate a separate cluster for this index, and I propose to add 3 more machines to the cluster and use shard allocation awareness only for this index and divide it into 3 primary and 1 replica shard  
what do you think this is right approach? or what is the best way to do it in your opinion?

---

<div class="post-metadata">

**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\
**Post date:** [October 28, 2021, 2:31pm UTC](https://discuss.elastic.co/t/best-solution-for-this-case/287900/2 "2021-10-28T14:31:12Z")

</div>

Hi @auto_reply_007

First I suggest you read this very informative section on sizing shards [here](https://www.elastic.co/guide/en/elasticsearch/reference/current/size-your-shards.html)

Just a quick analysis I would break that index up into probably at least 5 shards with one replica, to get those shards down below 50 gigabytes per shard.

Also does That index need to be in a single index with an index pattern perhaps you could break that index into multiple indexes And as well as reducing the shard size.

After the allocation awareness there's some pros and cons to that now you'll be limiting down to less nodes which means less primary shards and may not suit your purpose.

Second if this is a production cluster and you only have one master node you are it at risk of cluster failure if you lose that masternode.

---

<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:** [November 25, 2021, 2:31pm UTC](https://discuss.elastic.co/t/best-solution-for-this-case/287900/3 "2021-11-25T14:31:54Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.