2013-08-28 19:24:34 -04:00
|
|
|
[[search-request-preference]]
|
|
|
|
=== Preference
|
|
|
|
|
2017-03-29 12:52:49 -04:00
|
|
|
Controls a `preference` of which shard copies on which to execute the
|
|
|
|
search. By default, the operation is randomized among the available shard copies.
|
2013-08-28 19:24:34 -04:00
|
|
|
|
2014-07-09 05:12:43 -04:00
|
|
|
The `preference` is a query string parameter which can be set to:
|
2013-08-28 19:24:34 -04:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
`_primary`::
|
|
|
|
The operation will go and be executed only on the primary
|
|
|
|
shards.
|
|
|
|
|
|
|
|
`_primary_first`::
|
|
|
|
The operation will go and be executed on the primary
|
|
|
|
shard, and if not available (failover), will execute on other shards.
|
|
|
|
|
2015-07-14 13:46:43 -04:00
|
|
|
`_replica`::
|
|
|
|
The operation will go and be executed only on a replica shard.
|
|
|
|
|
|
|
|
`_replica_first`::
|
|
|
|
The operation will go and be executed only on a replica shard, and if
|
|
|
|
not available (failover), will execute on other shards.
|
|
|
|
|
2013-08-28 19:24:34 -04:00
|
|
|
`_local`::
|
|
|
|
The operation will prefer to be executed on a local
|
|
|
|
allocated shard if possible.
|
|
|
|
|
2016-06-14 21:34:24 -04:00
|
|
|
`_prefer_nodes:abc,xyz`::
|
|
|
|
Prefers execution on the nodes with the provided
|
|
|
|
node ids (`abc` or `xyz` in this case) if applicable.
|
2013-08-28 19:24:34 -04:00
|
|
|
|
|
|
|
`_shards:2,3`::
|
|
|
|
Restricts the operation to the specified shards. (`2`
|
|
|
|
and `3` in this case). This preference can be combined with other
|
2016-10-07 08:17:01 -04:00
|
|
|
preferences but it has to appear first: `_shards:2,3|_primary`
|
2013-08-28 19:24:34 -04:00
|
|
|
|
2015-06-01 18:25:04 -04:00
|
|
|
`_only_nodes`::
|
2017-02-04 06:05:03 -05:00
|
|
|
Restricts the operation to nodes specified in <<cluster,node specification>>
|
2015-06-01 18:25:04 -04:00
|
|
|
|
2013-08-28 19:24:34 -04:00
|
|
|
Custom (string) value::
|
|
|
|
A custom value will be used to guarantee that
|
|
|
|
the same shards will be used for the same custom value. This can help
|
|
|
|
with "jumping values" when hitting different shards in different refresh
|
|
|
|
states. A sample value can be something like the web session id, or the
|
|
|
|
user name.
|
|
|
|
|
2014-07-09 05:12:43 -04:00
|
|
|
For instance, use the user's session ID to ensure consistent ordering of results
|
|
|
|
for the user:
|
|
|
|
|
|
|
|
[source,js]
|
|
|
|
------------------------------------------------
|
2016-05-18 08:34:22 -04:00
|
|
|
GET /_search?preference=xyzabc123
|
2014-07-09 05:12:43 -04:00
|
|
|
{
|
|
|
|
"query": {
|
|
|
|
"match": {
|
|
|
|
"title": "elasticsearch"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
------------------------------------------------
|
2016-05-18 08:34:22 -04:00
|
|
|
// CONSOLE
|
2014-07-09 05:12:43 -04:00
|
|
|
|