# Search preference and primary shard balancing

**URL:** <https://discuss.elastic.co/t/search-preference-and-primary-shard-balancing/7850>\
**Category:** Elasticsearch\
**Created:** [May 24, 2012, 8:58pm UTC](https://discuss.elastic.co/t/search-preference-and-primary-shard-balancing/7850 "2012-05-24T20:58:58Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![ppearcy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ppearcy/32/980_2.png) [@ppearcy](https://discuss.elastic.co/u/ppearcy)\
**Post date:** [May 24, 2012, 8:58pm UTC](https://discuss.elastic.co/t/search-preference-and-primary-shard-balancing/7850/1 "2012-05-24T20:58:58Z")

</div>

Hey,  
In the process of moving from 0.16.5 to the latest 0.19.x release.  
Loving all the new features and functionality.

One piece of functionality that I thought would enable me to improve  
performance is the search preference behavior. Using the  
\_primary\_first behavior, my thought was that this would allow only one  
of the replicas to be warmed up and take care of handling all the  
searches. Basically, achieving the performance of no replicas while  
keeping the high availability.

In practice, however, the least recently rebooted machine ends up  
holding all of the primary replicas which pretty much means you end  
up with one server handling all the queries.

I've seen the primary shard balancing discussion before and the  
consensus was that it didn't make sense because there isn't much  
overhead for a primary shard. Perhaps allowing primary shard balancing  
would make sense for this use case?

Thanks!  
Paul

---

<div class="post-metadata">

**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\
**Post date:** [May 29, 2012, 6:22pm UTC](https://discuss.elastic.co/t/search-preference-and-primary-shard-balancing/7850/2 "2012-05-29T18:22:16Z")

</div>

The \_primary\_first option was not really designed for this... :), there is  
a thread and an issue of being able to flip a switch on a shard and making  
a replica of it the primary, this might help in this case.

On Thu, May 24, 2012 at 10:58 PM, ppearcy [ppearcy@gmail.com](mailto:ppearcy@gmail.com) wrote:

> Hey,  
> In the process of moving from 0.16.5 to the latest 0.19.x release.  
> Loving all the new features and functionality.
> 
> One piece of functionality that I thought would enable me to improve  
> performance is the search preference behavior. Using the  
> \_primary\_first behavior, my thought was that this would allow only one  
> of the replicas to be warmed up and take care of handling all the  
> searches. Basically, achieving the performance of no replicas while  
> keeping the high availability.
> 
> In practice, however, the least recently rebooted machine ends up  
> holding all of the primary replicas which pretty much means you end  
> up with one server handling all the queries.
> 
> I've seen the primary shard balancing discussion before and the  
> consensus was that it didn't make sense because there isn't much  
> overhead for a primary shard. Perhaps allowing primary shard balancing  
> would make sense for this use case?
> 
> Thanks!  
> Paul

---

<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:26am UTC](https://discuss.elastic.co/t/search-preference-and-primary-shard-balancing/7850/3 "2017-07-06T03:26:35Z")

</div>