# Shard allocation **URL:** \ **Category:** Elasticsearch\ **Created:** [September 30, 2024, 5:24pm UTC](https://discuss.elastic.co/t/shard-allocation/368035 "2024-09-30T17:24:58Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![INS](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ins/32/92827_2.png) [@INS](https://discuss.elastic.co/u/INS)\ **Post date:** [September 30, 2024, 5:24pm UTC](https://discuss.elastic.co/t/shard-allocation/368035/1 "2024-09-30T17:24:58Z")
Hi I have a 9 data nodes, what kind of settings should I use for insure allocation one index with 9 shards and 1 replica for (one primary shard per data node)??? ---
**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:** [September 30, 2024, 5:41pm UTC](https://discuss.elastic.co/t/shard-allocation/368035/2 "2024-09-30T17:41:31Z")
You can not control where primary shards are placed, but not having primaries evenly spread out is generally not an issue as primaries and replicas generally do the same work. In order to force a maximum of 2 shards to be allocated per node (any combination of primary and replicas) you can use the [total shards per node index setting](https://www.elastic.co/guide/en/elasticsearch/reference/current/allocation-total-shards.html), but be aware that this may prevent replicas to be reallocated of you were to lose one or more nodes. ---
**Author:** ![INS](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ins/32/92827_2.png) [@INS](https://discuss.elastic.co/u/INS)\ **Post date:** [September 30, 2024, 5:44pm UTC](https://discuss.elastic.co/t/shard-allocation/368035/3 "2024-09-30T17:44:42Z")
ok. so my thoughts are if I have one primary shard from one index on each of node it could be much better performance, of course NW will be covered that good condition in search ---
**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:** [September 30, 2024, 5:46pm UTC](https://discuss.elastic.co/t/shard-allocation/368035/4 "2024-09-30T17:46:35Z")
If you have 2 primary shards or 2 replica shards on a node should make very little difference, if any. ---
**Author:** ![INS](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ins/32/92827_2.png) [@INS](https://discuss.elastic.co/u/INS)\ **Post date:** [September 30, 2024, 5:48pm UTC](https://discuss.elastic.co/t/shard-allocation/368035/5 "2024-09-30T17:48:20Z")
so during search primary shards and replicas are involved in the same priority in search performance? ---
**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:** [September 30, 2024, 5:49pm UTC](https://discuss.elastic.co/t/shard-allocation/368035/6 "2024-09-30T17:49:37Z")
Yes. Each search request will hit one of the shards (equal probability) unless you explicitly specify it should prioritise primaries or replicas. ---
**Author:** ![INS](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ins/32/92827_2.png) [@INS](https://discuss.elastic.co/u/INS)\ **Post date:** [September 30, 2024, 5:53pm UTC](https://discuss.elastic.co/t/shard-allocation/368035/7 "2024-09-30T17:53:42Z")
which one parameter is handling for such priority in search ---
**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:** [September 30, 2024, 6:43pm UTC](https://discuss.elastic.co/t/shard-allocation/368035/8 "2024-09-30T18:43:53Z")
I would recommend not trying to control this as the default behaviour generally is very good and can handle changes and issues in the cluster. If you still want to experiment with it it is done by [by specifying preference as part of the search request](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-search.html#search-preference).