# Does es node prioritize local shard for searching?

**URL:** <https://discuss.elastic.co/t/does-es-node-prioritize-local-shard-for-searching/328790>\
**Category:** Elasticsearch\
**Created:** [March 29, 2023, 8:13am UTC](https://discuss.elastic.co/t/does-es-node-prioritize-local-shard-for-searching/328790 "2023-03-29T08:13:02Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![clp991666](https://avatars.discourse-cdn.com/v4/letter/c/e47c2d/32.png) [@clp991666](https://discuss.elastic.co/u/clp991666)\
**Post date:** [March 29, 2023, 8:13am UTC](https://discuss.elastic.co/t/does-es-node-prioritize-local-shard-for-searching/328790/1 "2023-03-29T08:13:02Z")

</div>

Hi,

I use es cluster to serve a small index (\<1G) for searching and aggregation and so only 1 shard is assigned and 1 replica. As 1 node does not able to serve all the request fast enough so the cluster scale to 10 nodes.

I increase the number of replica to 9 so that the total replica is (1+9) so that every node have the copy of the single shard.

I put a load balancer in front of all the nodes so that the http request is distributed across the nodes.

I would like to ask the following:

1. Is it a general good practice for my case?

2. Is it a good practice to increase the number of replica so that every node have a local copy of the shard in order to increase the performance?

3. When the node receive a request, does it prefer to use the shard available in local before reaching to other nodes? should i use `preference=_local` to force the node to uses its local shard from the documentation[1]?

[1] [Search shard routing | Elasticsearch Guide [8.6] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-shard-routing.html)

---

<div class="post-metadata">

**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\
**Post date:** [March 29, 2023, 8:17am UTC](https://discuss.elastic.co/t/does-es-node-prioritize-local-shard-for-searching/328790/2 "2023-03-29T08:17:59Z")

</div>

Welcome to our community! 😃

1. Does it work? If so then yes
2. For your use case, yes
3. It will pick the primary of any one of your replicas at random. You might be better off using preference as you mention

---

<div class="post-metadata">

**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\
**Post date:** [March 29, 2023, 8:19am UTC](https://discuss.elastic.co/t/does-es-node-prioritize-local-shard-for-searching/328790/3 "2023-03-29T08:19:24Z")

</div>

> [@clp991666](#):
>
> Is it a general good practice for my case?

Yes. I see nothing wrong with this approach as long as clients use long running connections and the load balancer distributes load evenly.

> [@clp991666](#):
>
> Is it a good practice to increase the number of replica so that every node have a local copy of the shard in order to increase the performance?

Yes. If you have a small data set that fits in the OS page cache and a high number of concurrent requests this is great.

> [@clp991666](#):
>
> When the node receive a request, does it prefer to use the shard available in local before reaching to other nodes? should i use `preference=_local` to force the node to uses its local shard from the documentation[1]?

I believe the default is adaptive selection, which may not favour the local shard. As this setting exists I would use it, at least as long as the load is evenly distributed by the load balancer.

---

<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:** [April 26, 2023, 8:19am UTC](https://discuss.elastic.co/t/does-es-node-prioritize-local-shard-for-searching/328790/4 "2023-04-26T08:19:39Z")

</div>

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