I took a look at some of the changes that Elasticsearch RC1 brings and I
was wondering what use cases you found for tribe nodes. What are the
benefits of using a tribe node over multiple clusters versus just having
more indexes in the same cluster.
The tribe node can be useful if your organization is maintaining several
clusters (for whatever reasons) but you want to search all of them.
Also useful could be transferring data between clusters by a single client
in a single step.
Reasons can be organizational, or geographical, or logical. Maybe you have
grown several clusters that you do not want to merge, or several data
centers, or you want to compare data in a staging area with current
production cluster, so you could span internal and external visible
clusters simply by executing a tribe node search.
HI Jorg,
I posted a question for the same issue yesterday and I was referenced to
look at
.
My question is lets say I want to query across multiple cluster using
Kibana, then do I need to put tribe node details in elasticsearch ? Also,
is it a new type of node on top of Master, client, data ?
Thanks,
Deepak
On Thursday, January 16, 2014 6:40:10 AM UTC-8, Jörg Prante wrote:
The tribe node can be useful if your organization is maintaining several
clusters (for whatever reasons) but you want to search all of them.
Also useful could be transferring data between clusters by a single client
in a single step.
Reasons can be organizational, or geographical, or logical. Maybe you have
grown several clusters that you do not want to merge, or several data
centers, or you want to compare data in a staging area with current
production cluster, so you could span internal and external visible
clusters simply by executing a tribe node search.
A tribe node is built into a usual Node, so there is no special tribe node
class. If you pass parameter like "tribe.t1.cluster.name" etc. to the Node
settings, a tribe service class is used and performs all the necessary work
in the background. Basically the API stays the same but certain features
will throw errors. In fact, the tribe mode opens one or more internal nodes
that attach to different clusters, like specified. By listening to the
cluster states, they can be merged.
Because the client API does not change compared to a usual Java Node
client, I think Kibana can make use of tribe mode right out of the box (but
bare with me I am no Kibana expert).
Does anyone know if a tribe node can talk to v0.90.* clusters? ie the tribe
functionality is only required on the designated tribe node and not all
it's connected clusters.
A tribe node is built into a usual Node, so there is no special tribe node
class. If you pass parameter like "tribe.t1.cluster.name" etc. to the
Node settings, a tribe service class is used and performs all the necessary
work in the background. Basically the API stays the same but certain
features will throw errors. In fact, the tribe mode opens one or more
internal nodes that attach to different clusters, like specified. By
listening to the cluster states, they can be merged.
Because the client API does not change compared to a usual Java Node
client, I think Kibana can make use of tribe mode right out of the box (but
bare with me I am no Kibana expert).
Does anyone know if a tribe node can talk to v0.90.* clusters? ie the tribe functionality is only required on the designated tribe node and not all it's connected clusters.
A tribe node is built into a usual Node, so there is no special tribe node class. If you pass parameter like "tribe.t1.cluster.name" etc. to the Node settings, a tribe service class is used and performs all the necessary work in the background. Basically the API stays the same but certain features will throw errors. In fact, the tribe mode opens one or more internal nodes that attach to different clusters, like specified. By listening to the cluster states, they can be merged.
Because the client API does not change compared to a usual Java Node client, I think Kibana can make use of tribe mode right out of the box (but bare with me I am no Kibana expert).
0.90.* and 1.0.0.RC1 node clients can not talk to each other, discovery
fails with errors like
[2014-01-16 23:45:40,885][WARN ][discovery.zen.ping.multicast] [John
Falsworth] failed to read requesting data from /192.168.1.113:54328
java.io.IOException: No transport address mapped to [17519]
at
org.elasticsearch.common.transport.TransportAddressSerializers.addressFromStream(TransportAddressSerializers.java:71)
at
org.elasticsearch.cluster.node.DiscoveryNode.readFrom(DiscoveryNode.java:267)
at
org.elasticsearch.cluster.node.DiscoveryNode.readNode(DiscoveryNode.java:257)
at
org.elasticsearch.discovery.zen.ping.multicast.MulticastZenPing$Receiver.run(MulticastZenPing.java:410)
at java.lang.Thread.run(Thread.java:724)
and tribe mode will not magically overcome this situation.
Le jeudi 16 janvier 2014 17:52:25 UTC-5, Jörg Prante a écrit :
0.90.* and 1.0.0.RC1 node clients can not talk to each other, discovery
fails with errors like
[2014-01-16 23:45:40,885][WARN ][discovery.zen.ping.multicast] [John
Falsworth] failed to read requesting data from /192.168.1.113:54328
java.io.IOException: No transport address mapped to [17519]
at
org.elasticsearch.common.transport.TransportAddressSerializers.addressFromStream(TransportAddressSerializers.java:71)
at
org.elasticsearch.cluster.node.DiscoveryNode.readFrom(DiscoveryNode.java:267)
at
org.elasticsearch.cluster.node.DiscoveryNode.readNode(DiscoveryNode.java:257)
at
org.elasticsearch.discovery.zen.ping.multicast.MulticastZenPing$Receiver.run(MulticastZenPing.java:410)
at java.lang.Thread.run(Thread.java:724)
and tribe mode will not magically overcome this situation.
Le jeudi 16 janvier 2014 17:52:25 UTC-5, Jörg Prante a écrit :
0.90.* and 1.0.0.RC1 node clients can not talk to each other, discovery
fails with errors like
[2014-01-16 23:45:40,885][WARN ][discovery.zen.ping.multicast] [John
Falsworth] failed to read requesting data from /192.168.1.113:54328
java.io.IOException: No transport address mapped to [17519]
at org.elasticsearch.common.transport.TransportAddressSerializers.
addressFromStream(TransportAddressSerializers.java:71)
at org.elasticsearch.cluster.node.DiscoveryNode.readFrom(
DiscoveryNode.java:267)
at org.elasticsearch.cluster.node.DiscoveryNode.readNode(
DiscoveryNode.java:257)
at org.elasticsearch.discovery.zen.ping.multicast.
MulticastZenPing$Receiver.run(MulticastZenPing.java:410)
at java.lang.Thread.run(Thread.java:724)
and tribe mode will not magically overcome this situation.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
