Cross-cluster search provides details about search on each clusteredit
Previously with cross-cluster searches using ccs_minimize_roundtrips=true,
when an error was returned, it was unclear which cluster caused the problem.
We have improved the search response for both synchronous and asynchronous
searches to have status and error details in the
_clusters section, listing
each cluster involved in the search by name (alias). It includes
status info, shard accounting counts and error information that
are updated incrementally as the search progresses. In case of errors or partial
results, you can use this information to determine to what extent the search
results might be usable and if any follow-up action is needed to reduce errors.
The search on each cluster can be in one of 5 states:
SUCCESSFUL (all shards were successfully searched),
PARTIAL (some shard
searches failed, but at least one succeeded and partial data has been returned),
SKIPPED (no shards were successfully searched on a cluster marked with
FAILED (no shards were successfully searched on a
cluster marked with skip_unavailable=false).
Kibana users can access this information by viewing the search response in the Inspect flyout.
Exclude clusters from a cross-cluster searchedit
When doing a cross-cluster search, if you use a wildcard to include a list of clusters, you
can explicitly exclude one or more clusters with a minus sign (-). To exclude an entire cluster,
put the minus sign in front of the cluster alias, such as:
In that case, clusters with the alias "remote3" and "remote5" will be excluded from the search.
For this feature, you must use
* in the index position or an error will be returned.
Enable parallel knn search across segmentsedit
Elasticsearch has, until now, performed search sequentially across the segments within each shard. This change makes knn queries faster on shards that are made of more than one segment by rewriting and collecting each segment in parallel.
Change pre-configured and cached analyzer components to use IndexVersion instead of Versionedit
As part of ongoing refactoring work, we are separating out various component versions into their own types.
For this, we have introduced a new
IndexVersion type to represent the version of index data and metadata.
This PR changes the types used to obtain pre-configured components from Version to IndexVersion, with corresponding changes to method names.
Prior to 8.10, there is a one-to-one mapping between node version and index version, with corresponding constants in the IndexVersion class. Starting in 8.10, IndexVersion is versioned independently of node version, and will be a simple incrementing number. For more information on how to use IndexVersion and other version types, please see the contributing guide.
API key based cross-cluster search and replication (Beta)edit
This new model uses a cross-cluster API key to authenticate and authorize cross-cluster operations to a remote cluster. It completely separates network security controls between the local and remote cluster as well as offers administrators of both the local and the remote cluster fine-grained access controls.