|
@@ -102,12 +102,24 @@ is as follows:
|
|
|
. Combine the results and respond. Note that in the case of get by ID look up, only one shard is relevant and this step can be skipped.
|
|
|
|
|
|
[float]
|
|
|
-==== Failure handling
|
|
|
+[[shard-failures]]
|
|
|
+==== Shard failures
|
|
|
+
|
|
|
+When a shard fails to respond to a read request, the coordinating node sends the
|
|
|
+request to another shard copy in the same replication group. Repeated failures
|
|
|
+can result in no available shard copies.
|
|
|
+
|
|
|
+To ensure fast responses, the following APIs will
|
|
|
+respond with partial results if one or more shards fail:
|
|
|
+
|
|
|
+* <<search-search, Search>>
|
|
|
+* <<search-multi-search, Multi Search>>
|
|
|
+* <<docs-bulk, Bulk>>
|
|
|
+* <<docs-multi-get, Multi Get>>
|
|
|
|
|
|
-When a shard fails to respond to a read request, the coordinating node will select another copy from the same replication group
|
|
|
-and send the shard level search request to that copy instead. Repetitive failures can result in no shard copies being available.
|
|
|
-In some cases, such as `_search`, Elasticsearch will prefer to respond fast, albeit with partial results, instead of waiting
|
|
|
-for the issue to be resolved (partial results are indicated in the `_shards` header of the response).
|
|
|
+Responses containing partial results still provide a `200 OK` HTTP status code.
|
|
|
+Shard failures are indicated by the `timed_out` and `_shards` fields of
|
|
|
+the response header.
|
|
|
|
|
|
[float]
|
|
|
=== A few simple implications
|