2017-04-11 03:24:40 -04:00
|
|
|
[[cluster-remote-info]]
|
2019-10-22 13:27:31 -04:00
|
|
|
=== Remote cluster info API
|
|
|
|
|
++++
|
|
|
|
|
<titleabbrev>Remote cluster info</titleabbrev>
|
|
|
|
|
++++
|
2017-04-11 03:24:40 -04:00
|
|
|
|
2019-08-14 11:07:24 -04:00
|
|
|
Returns configured remote cluster information.
|
2017-04-11 03:24:40 -04:00
|
|
|
|
|
|
|
|
|
2019-08-14 11:07:24 -04:00
|
|
|
[[cluster-remote-info-api-request]]
|
|
|
|
|
==== {api-request-title}
|
2017-04-11 03:24:40 -04:00
|
|
|
|
2019-08-14 11:07:24 -04:00
|
|
|
`GET /_remote/info`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[[cluster-remote-info-api-desc]]
|
|
|
|
|
==== {api-description-title}
|
|
|
|
|
|
|
|
|
|
The cluster remote info API allows you to retrieve all of the configured
|
|
|
|
|
remote cluster information. It returns connection and endpoint information keyed
|
|
|
|
|
by the configured remote cluster alias.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[[cluster-remote-info-api-response-body]]
|
|
|
|
|
==== {api-response-body-title}
|
2017-04-11 03:24:40 -04:00
|
|
|
|
|
|
|
|
`seeds`::
|
|
|
|
|
The configured initial seed transport addresses of the remote cluster.
|
|
|
|
|
|
|
|
|
|
`connected`::
|
|
|
|
|
True if there is at least one connection to the remote cluster.
|
|
|
|
|
|
|
|
|
|
`num_nodes_connected`::
|
|
|
|
|
The number of connected nodes in the remote cluster.
|
|
|
|
|
|
2018-08-22 05:27:37 -04:00
|
|
|
`max_connections_per_cluster`::
|
2017-04-11 03:24:40 -04:00
|
|
|
The maximum number of connections maintained for the remote cluster.
|
|
|
|
|
|
|
|
|
|
`initial_connect_timeout`::
|
|
|
|
|
The initial connect timeout for remote cluster connections.
|
Cross Cluster Search: make remote clusters optional (#27182)
Today Cross Cluster Search requires at least one node in each remote cluster to be up once the cross cluster search is run. Otherwise the whole search request fails despite some of the data (either local and/or remote) is available. This happens when performing the _search/shards calls to find out which remote shards the query has to be executed on. This scenario is different from shard failures that may happen later on when the query is actually executed, in case e.g. remote shards are missing, which is not going to fail the whole request but rather yield partial results, and the _shards section in the response will indicate that.
This commit introduces a boolean setting per cluster called search.remote.$cluster_alias.skip_if_disconnected, set to false by default, which allows to skip certain clusters if they are down when trying to reach them through a cross cluster search requests. By default all clusters are mandatory.
Scroll requests support such setting too when they are first initiated (first search request with scroll parameter), but subsequent scroll rounds (_search/scroll endpoint) will fail if some of the remote clusters went down meanwhile.
The search API response contains now a new _clusters section, similar to the _shards section, that gets returned whenever one or more clusters were disconnected and got skipped:
"_clusters" : {
"total" : 3,
"successful" : 2,
"skipped" : 1
}
Such section won't be part of the response if no clusters have been skipped.
The per cluster skip_unavailable setting value has also been added to the output of the remote/info API.
2017-11-21 05:41:47 -05:00
|
|
|
|
2019-08-15 13:23:25 -04:00
|
|
|
[[skip-unavailable]]
|
Cross Cluster Search: make remote clusters optional (#27182)
Today Cross Cluster Search requires at least one node in each remote cluster to be up once the cross cluster search is run. Otherwise the whole search request fails despite some of the data (either local and/or remote) is available. This happens when performing the _search/shards calls to find out which remote shards the query has to be executed on. This scenario is different from shard failures that may happen later on when the query is actually executed, in case e.g. remote shards are missing, which is not going to fail the whole request but rather yield partial results, and the _shards section in the response will indicate that.
This commit introduces a boolean setting per cluster called search.remote.$cluster_alias.skip_if_disconnected, set to false by default, which allows to skip certain clusters if they are down when trying to reach them through a cross cluster search requests. By default all clusters are mandatory.
Scroll requests support such setting too when they are first initiated (first search request with scroll parameter), but subsequent scroll rounds (_search/scroll endpoint) will fail if some of the remote clusters went down meanwhile.
The search API response contains now a new _clusters section, similar to the _shards section, that gets returned whenever one or more clusters were disconnected and got skipped:
"_clusters" : {
"total" : 3,
"successful" : 2,
"skipped" : 1
}
Such section won't be part of the response if no clusters have been skipped.
The per cluster skip_unavailable setting value has also been added to the output of the remote/info API.
2017-11-21 05:41:47 -05:00
|
|
|
`skip_unavailable`::
|
|
|
|
|
Whether the remote cluster is skipped in case it is searched through
|
2019-03-15 10:54:45 -04:00
|
|
|
a {ccs} request but none of its nodes are available.
|
