So if I installed elasticsearch on my 3 servers (all on the same
network, with multicast enabled (is that an apt-get install?)),
...however you install ES
used the same clustername for them, and they could all see each other
on post 9300, would ...
An index created on one with 2 replicas automatically replicate
across the 3 servers?
Yes
A document indexed to one server automatically be replicated to 2
other replicas on the other two servers?
Yes
A fallen-over node be able to bring itself back up, repair itself,
and add itself back into the cluster? Would the service wrapper do
this?
Well, depends...
If a node dies, the service wrapper should restart it.
If a node leaves the cluster for some reason (eg network outage) then it
won't rejoin the cluster automatically (unless something has changed
recently that I don't know about).
You would have to stop and start the node manually for it to rejoin the
cluster. And it is possible that you could have docs indexed just to
this node and not to the other two nodes, which you would then lose.
There is no conflict resolution available.
That's fantastic, thankyou very much for answering so fully and patiently.
I have just one last question -- is it definitely port 9300 that the nodes
need to be able to see each other on, rather than 9200 (like for local
development)?
& thanks again,
Doug.
So if I installed elasticsearch on my 3 servers (all on the same
network, with multicast enabled (is that an apt-get install?)),
...however you install ES
used the same clustername for them, and they could all see each other
on post 9300, would ...
An index created on one with 2 replicas automatically replicate
across the 3 servers?
Yes
A document indexed to one server automatically be replicated to 2
other replicas on the other two servers?
Yes
A fallen-over node be able to bring itself back up, repair itself,
and add itself back into the cluster? Would the service wrapper do
this?
Well, depends...
If a node dies, the service wrapper should restart it.
If a node leaves the cluster for some reason (eg network outage) then it
won't rejoin the cluster automatically (unless something has changed
recently that I don't know about).
You would have to stop and start the node manually for it to rejoin the
cluster. And it is possible that you could have docs indexed just to
this node and not to the other two nodes, which you would then lose.
There is no conflict resolution available.
Nodes talk to each other through proprietary binary protocol, by default it
is bound to ports starting at 9300. However, it can be fully customized:
Every node can also expose its API via HTTP, by default this is allowed and
is bound to ports starting at 9200. This can be customized as well:
This is what many [third-party] clients use to talk to nodes in cluster.
Regards,
Lukas
On Mon, Oct 17, 2011 at 11:30 PM, doug livesey biot023@gmail.com wrote:
That's fantastic, thankyou very much for answering so fully and patiently.
I have just one last question -- is it definitely port 9300 that the nodes
need to be able to see each other on, rather than 9200 (like for local
development)?
& thanks again,
Doug.
So if I installed elasticsearch on my 3 servers (all on the same
network, with multicast enabled (is that an apt-get install?)),
...however you install ES
used the same clustername for them, and they could all see each other
on post 9300, would ...
An index created on one with 2 replicas automatically replicate
across the 3 servers?
Yes
A document indexed to one server automatically be replicated to 2
other replicas on the other two servers?
Yes
A fallen-over node be able to bring itself back up, repair itself,
and add itself back into the cluster? Would the service wrapper do
this?
Well, depends...
If a node dies, the service wrapper should restart it.
If a node leaves the cluster for some reason (eg network outage) then it
won't rejoin the cluster automatically (unless something has changed
recently that I don't know about).
You would have to stop and start the node manually for it to rejoin the
cluster. And it is possible that you could have docs indexed just to
this node and not to the other two nodes, which you would then lose.
There is no conflict resolution available.
One more think that I am not 100% sure that was explained in this
discussion, is that when you search on a node, the search will automatically
be balanced and executed across several shards (matching the search
request), and balanced across several nodes. So, elasticsearch will do the
distributed search part for you.
Even if you have 1 index, with 5 shards, and 2 replicas on 3 node cluster,
the search request will end up executed on 5 different shards, across
several nodes.
Every node can also expose its API via HTTP, by default this is allowed and
is bound to ports starting at 9200. This can be customized as well: Elasticsearch Platform — Find real-time answers at scale | Elastic
This is what many [third-party] clients use to talk to nodes in cluster.
Regards,
Lukas
On Mon, Oct 17, 2011 at 11:30 PM, doug livesey biot023@gmail.com wrote:
That's fantastic, thankyou very much for answering so fully and patiently.
I have just one last question -- is it definitely port 9300 that the nodes
need to be able to see each other on, rather than 9200 (like for local
development)?
& thanks again,
Doug.
So if I installed elasticsearch on my 3 servers (all on the same
network, with multicast enabled (is that an apt-get install?)),
...however you install ES
used the same clustername for them, and they could all see each other
on post 9300, would ...
An index created on one with 2 replicas automatically replicate
across the 3 servers?
Yes
A document indexed to one server automatically be replicated to 2
other replicas on the other two servers?
Yes
A fallen-over node be able to bring itself back up, repair itself,
and add itself back into the cluster? Would the service wrapper do
this?
Well, depends...
If a node dies, the service wrapper should restart it.
If a node leaves the cluster for some reason (eg network outage) then it
won't rejoin the cluster automatically (unless something has changed
recently that I don't know about).
You would have to stop and start the node manually for it to rejoin the
cluster. And it is possible that you could have docs indexed just to
this node and not to the other two nodes, which you would then lose.
There is no conflict resolution available.
Excellent, so literally the only thing I need to worry about with regards to
redundancy is implementing failover on the IP of the node I call.
Thanks very much,
Doug.
One more think that I am not 100% sure that was explained in this
discussion, is that when you search on a node, the search will automatically
be balanced and executed across several shards (matching the search
request), and balanced across several nodes. So, elasticsearch will do the
distributed search part for you.
Even if you have 1 index, with 5 shards, and 2 replicas on 3 node cluster,
the search request will end up executed on 5 different shards, across
several nodes.
Every node can also expose its API via HTTP, by default this is allowed
and is bound to ports starting at 9200. This can be customized as well: Elasticsearch Platform — Find real-time answers at scale | Elastic
This is what many [third-party] clients use to talk to nodes in cluster.
Regards,
Lukas
On Mon, Oct 17, 2011 at 11:30 PM, doug livesey biot023@gmail.com wrote:
That's fantastic, thankyou very much for answering so fully and
patiently.
I have just one last question -- is it definitely port 9300 that the
nodes need to be able to see each other on, rather than 9200 (like for local
development)?
& thanks again,
Doug.
So if I installed elasticsearch on my 3 servers (all on the same
network, with multicast enabled (is that an apt-get install?)),
...however you install ES
used the same clustername for them, and they could all see each other
on post 9300, would ...
An index created on one with 2 replicas automatically replicate
across the 3 servers?
Yes
A document indexed to one server automatically be replicated to 2
other replicas on the other two servers?
Yes
A fallen-over node be able to bring itself back up, repair itself,
and add itself back into the cluster? Would the service wrapper do
this?
Well, depends...
If a node dies, the service wrapper should restart it.
If a node leaves the cluster for some reason (eg network outage) then it
won't rejoin the cluster automatically (unless something has changed
recently that I don't know about).
You would have to stop and start the node manually for it to rejoin the
cluster. And it is possible that you could have docs indexed just to
this node and not to the other two nodes, which you would then lose.
There is no conflict resolution available.
Hi - So if I want my client to be aware of just one IP and if I want the load balancing to be automatically happen within ES, do I need to put something like Apache fail over mechanism before ES?
The reason is that I dont want my clients to be aware of any nodes except just one destination address.
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.