Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add back _primary* search preferences #41115

Closed
awick opened this issue Apr 11, 2019 · 3 comments
Closed

Add back _primary* search preferences #41115

awick opened this issue Apr 11, 2019 · 3 comments

Comments

@awick
Copy link

awick commented Apr 11, 2019 •
edited
Loading

We run large time based clusters with 1 primary and 1 replica on each node. We liked the primary* search options so that no extra heap or disk cache is used when searching, only the primary is loaded. With out the primary options, my assumption is now it is possible if multiple searches are done that multiple primary and replicas of every index could be loaded on every machine. For those of us with low volume of search that search a large amount of data, this would cut our memory cache/heap in almost 1/2.

The "The cache-related benefits of these options can also be obtained using _only_nodes, _prefer_nodes, or a custom string value instead." from the online docs doesn't apply to us since every node has a shard for disk capacity and speed.

Am I thinking about this wrong?
@DaveCTurner
Copy link
Contributor

This question is better suited for the discussion forum, so I hope you don't mind if I close it. Could you open a thread in the forum and link to it from here?

@awick
Copy link
Author

awick commented Apr 12, 2019

@DaveCTurner Its a feature request, or those must be discussed first on the forum?

@awick
Copy link
Author

awick commented Apr 12, 2019

https://discuss.elastic.co/t/add-back-primary-search-preferences/176598

DaveCTurner added a commit to DaveCTurner/elasticsearch that referenced this issue Apr 12, 2019
@DaveCTurner
Assert the stability of custom search preferences
35a25ab 
Today the `?preference=custom_string_value` search preference will only change
its choice of a shard copy if something changes the `IndexShardRoutingTable`
for that specific shard. Users can use this behaviour to route searches to a
consistent set of shard copies, which means they can reliably hit copies with
hot caches, and use the other copies only for redundancy in case of failure.
However we do not assert this property anywhere, so we might break it in
future.

This commit adds a test that shows that searches are routed consistently even
if other indices are created/rebalanced/deleted.

Relates https://discuss.elastic.co/t/176598, elastic#41115, elastic#26791
@DaveCTurner DaveCTurner mentioned this issue Apr 12, 2019
Merged
DaveCTurner added a commit that referenced this issue Apr 17, 2019
@DaveCTurner
Assert the stability of custom search preferences (#41150)
48fea49 
Today the `?preference=custom_string_value` search preference will only change
its choice of a shard copy if something changes the `IndexShardRoutingTable`
for that specific shard. Users can use this behaviour to route searches to a
consistent set of shard copies, which means they can reliably hit copies with
hot caches, and use the other copies only for redundancy in case of failure.
However we do not assert this property anywhere, so we might break it in
future.

This commit adds a test that shows that searches are routed consistently even
if other indices are created/rebalanced/deleted.

Relates https://discuss.elastic.co/t/176598, #41115, #26791
DaveCTurner added a commit that referenced this issue Apr 17, 2019
@DaveCTurner
Assert the stability of custom search preferences (#41150)
2670ed2 
Today the `?preference=custom_string_value` search preference will only change
its choice of a shard copy if something changes the `IndexShardRoutingTable`
for that specific shard. Users can use this behaviour to route searches to a
consistent set of shard copies, which means they can reliably hit copies with
hot caches, and use the other copies only for redundancy in case of failure.
However we do not assert this property anywhere, so we might break it in
future.

This commit adds a test that shows that searches are routed consistently even
if other indices are created/rebalanced/deleted.

Relates https://discuss.elastic.co/t/176598, #41115, #26791
gurkankaymak pushed a commit to gurkankaymak/elasticsearch that referenced this issue May 27, 2019
@DaveCTurner
Assert the stability of custom search preferences (elastic#41150)
0715e50 
Today the `?preference=custom_string_value` search preference will only change
its choice of a shard copy if something changes the `IndexShardRoutingTable`
for that specific shard. Users can use this behaviour to route searches to a
consistent set of shard copies, which means they can reliably hit copies with
hot caches, and use the other copies only for redundancy in case of failure.
However we do not assert this property anywhere, so we might break it in
future.

This commit adds a test that shows that searches are routed consistently even
if other indices are created/rebalanced/deleted.

Relates https://discuss.elastic.co/t/176598, elastic#41115, elastic#26791
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@awick @DaveCTurner