OpenSearch/docs/reference/modules/tribe.asciidoc

75 lines
2.6 KiB
Plaintext
Raw Normal View History

[[modules-tribe]]
== Tribe node
The _tribes_ feature allows a _tribe node_ to act as a federated client across
multiple clusters.
The tribe node works by retrieving the cluster state from all connected
clusters and merging them into a global cluster state. With this information
at hand, it is able to perform read and write operations against the nodes in
all clusters as if they were local. Note that a tribe node needs to be able
to connect to each single node in every configured cluster.
The `elasticsearch.yml` config file for a tribe node just needs to list the
clusters that should be joined, for instance:
[source,yaml]
--------------------------------
tribe:
t1: <1>
cluster.name: cluster_one
t2: <1>
cluster.name: cluster_two
--------------------------------
2014-05-27 09:57:39 -04:00
<1> `t1` and `t2` are arbitrary names representing the connection to each
cluster.
The example above configures connections to two clusters, name `t1` and `t2`
respectively. The tribe node will create a <<modules-node,node client>> to
connect each cluster using <<unicast,unicast discovery>> by default. Any
other settings for the connection can be configured under `tribe.{name}`, just
like the `cluster.name` in the example.
The merged global cluster state means that almost all operations work in the
same way as a single cluster: distributed search, suggest, percolation,
indexing, etc.
However, there are a few exceptions:
* The merged view cannot handle indices with the same name in multiple
clusters. By default it will pick one of them, see later for on_conflict options.
* Master level read operations (eg <<cluster-state>>, <<cluster-health>>)
will automatically execute with a local flag set to true since there is
no master.
* Master level write operations (eg <<indices-create-index>>) are not
allowed. These should be performed on a single cluster.
The tribe node can be configured to block all write operations and all
metadata operations with:
[source,yaml]
--------------------------------
tribe:
blocks:
write: true
metadata: true
--------------------------------
The tribe node can also configure blocks on selected indices:
[source,yaml]
--------------------------------
tribe:
blocks:
write.indices: hk*,ldn*
metadata.indices: hk*,ldn*
--------------------------------
When there is a conflict and multiple clusters hold the same index, by default
the tribe node will pick one of them. This can be configured using the `tribe.on_conflict`
setting. It defaults to `any`, but can be set to `drop` (drop indices that have
a conflict), or `prefer_[tribeName]` to prefer the index from a specific tribe.