elasticsearch/docs/reference/cluster/remote-info.asciidoc

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

76 lines
2.2 KiB
Plaintext
Raw Normal View History

[[cluster-remote-info]]
=== Remote cluster info API
++++
<titleabbrev>Remote cluster info</titleabbrev>
++++
Returns configured remote cluster information.
[[cluster-remote-info-api-request]]
==== {api-request-title}
`GET /_remote/info`
[[cluster-remote-info-api-prereqs]]
==== {api-prereq-title}
* If the {es} {security-features} are enabled, you must have the `monitor` or
`manage` <<privileges-list-cluster,cluster privilege>> to use this API.
[[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}
`mode`::
Connection mode for the remote cluster. Returned values are `sniff` and
`proxy`.
`connected`::
True if there is at least one connection to 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 18:41:47 +08: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 18:41:47 +08:00
`skip_unavailable`::
Whether a {ccs} skips the remote cluster if its nodes are unavailable during the
search. If `true`, a {ccs} also ignores errors returned by the remote cluster.
Refer to <<skip-unavailable-clusters>>.
`seeds`::
Initial seed transport addresses of the remote cluster when sniff mode is
configured.
`num_nodes_connected`::
Number of connected nodes in the remote cluster when sniff mode is
configured.
`max_connections_per_cluster`::
Maximum number of connections maintained for the remote cluster when sniff
mode is configured.
`proxy_address`::
Address for remote connections when proxy mode is configured.
`num_proxy_sockets_connected`::
Number of open socket connections to the remote cluster when proxy mode
is configured.
`max_proxy_socket_connections`::
The maximum number of socket connections to the remote cluster when proxy
mode is configured.
[Docs] Misc doc update for RCS 2.0 (#98472) This PR adds docs for the following items: * Remote indices privileges * Remote cluster network settings * Remote cluster security settings * New privileges * New response field for RemoteInfo API List of preview pages: * [Remote indices in defining roles](https://elasticsearch_98472.docs-preview.app.elstc.co/guide/en/elasticsearch/reference/master/defining-roles.html#roles-remote-indices-priv) * [Remote indices in PutRole API](https://elasticsearch_98472.docs-preview.app.elstc.co/guide/en/elasticsearch/reference/master/security-api-put-role.html#security-api-put-role-request-body) * [Remote cluster server SSL settings](https://elasticsearch_98472.docs-preview.app.elstc.co/guide/en/elasticsearch/reference/master/security-settings.html#_remote_cluster_server_api_key_based_model_tlsssl_settings) * [Remote cluster client SSL settings](https://elasticsearch_98472.docs-preview.app.elstc.co/guide/en/elasticsearch/reference/master/security-settings.html#_remote_cluster_client_api_key_based_model_tlsssl_settings) * [Remote cluster network settings](https://elasticsearch_98472.docs-preview.app.elstc.co/guide/en/elasticsearch/reference/master/modules-network.html#remote-cluster-network-settings) and [here](https://elasticsearch_98472.docs-preview.app.elstc.co/guide/en/elasticsearch/reference/master/modules-network.html#common-network-settings) * [Remote cluster credentials setting](https://elasticsearch_98472.docs-preview.app.elstc.co/guide/en/elasticsearch/reference/master/remote-clusters-settings.html) * [New privileges](https://elasticsearch_98472.docs-preview.app.elstc.co/guide/en/elasticsearch/reference/master/security-privileges.html) * [New response field for RemoteInfo API](https://elasticsearch_98472.docs-preview.app.elstc.co/guide/en/elasticsearch/reference/master/cluster-remote-info.html#cluster-remote-info-api-response-body)
2023-08-16 08:11:21 +08:00
`cluster_credentials`::
beta:[]
This field presents and has value of `::es_redacted::` only when the
<<remote-clusters-api-key,remote cluster is configured with the API key based model>>.
Otherwise, the field is not present.