WARNING: Version 1.6 of Elasticsearch has passed its EOL date.
This documentation is no longer being maintained and may be removed. If you are running this version, we strongly advise you to upgrade. For the latest information, see the current release documentation.
Tribe node
editTribe node
editThe 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.
The elasticsearch.yml
config file for a tribe node just needs to list the
clusters that should be joined, for instance:
The example above configures connections to two clusters, name t1
and t2
respectively. The tribe node will create a node client to
connect each cluster using multicast 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 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:
tribe: blocks: write: true metadata: true
The tribe node can also configure blocks on indices explicitly:
tribe: blocks: indices.write: 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.