Imagine this situation, if the score in the search results in the same situation: because the search will be balanced between the copies of the polling request, the request may appear in different copies of the sequence returned, which affects the stability of the sorting results.
The search interface has the preference parameter provided: Curl localhost:9200/_search?preference=xyzabc123.
The parameters that can be used: _primary,_primary_first,_local,_only_node:xyz,_prefer_node:xyz and _shards:2,3 values.
The meanings of the parameters are as follows:
_primary: Search only performs search requests on primary shards, replicas do not participate in searches, performance is compromised, and performance levels are not scaled up.
_primary_first: Priority is performed on the primary Shard, and if the primary shard is hung, the request is executed on the replica.
_local: The search request takes precedence over local execution.
_ONLY_NODE:XYZ: The search is performed only on the XYZ node.
_PREFER_NODE:XYZ: The search request takes precedence over node xyz execution.
_shards:2,3: Search is performed only on Shards 2, 3, and can be used with _primary parameters such as: _shards:2,3;_primary
Random string: Specifies a random string that guarantees the same request and is assigned to the same copy, guaranteeing the stability of the same request result.
Reference: http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-request-preference.html
Distributed search Elasticsearch search results Sorting inconsistency problem