I have 2 boxes in a cluster that are geographically diverse (one on east
coast and one on west coast). The behavior I observe is that it does a
round robin (I'm making an assumption here based on every other response
time being much slower). Is there a way to configure the cluster so all
queries go to the master and only get routed to the non-master (further
away, less performant) if there's a failure on the master?
The elected master node is not related to where queries are routed. Same for elected primary shards. Searches are round robin between shard copies. You can control it by using shard allocation awareness (which will come handy when you have more nodes in the cluster to make sure copies of the shards are allocated properly across the two zones) which will also make sure that requests will go first to shards in their own zone. More info here: Elasticsearch Platform — Find real-time answers at scale | Elastic.
On Saturday, January 28, 2012 at 2:43 AM, Shane Witbeck wrote:
I have 2 boxes in a cluster that are geographically diverse (one on east coast and one on west coast). The behavior I observe is that it does a round robin (I'm making an assumption here based on every other response time being much slower). Is there a way to configure the cluster so all queries go to the master and only get routed to the non-master (further away, less performant) if there's a failure on the master?
What's the best way to determine which nodes/shards search requests are
routed to? I'm experimenting with cluster.routing.allocation attributes.
On Sunday, January 29, 2012 1:22:29 PM UTC-5, kimchy wrote:
The elected master node is not related to where queries are routed. Same
for elected primary shards. Searches are round robin between shard copies.
You can control it by using shard allocation awareness (which will come
handy when you have more nodes in the cluster to make sure copies of the
shards are allocated properly across the two zones) which will also make
sure that requests will go first to shards in their own zone. More info
here: Elasticsearch Platform — Find real-time answers at scale | Elastic.On Saturday, January 28, 2012 at 2:43 AM, Shane Witbeck wrote:
I have 2 boxes in a cluster that are geographically diverse (one on east
coast and one on west coast). The behavior I observe is that it does a
round robin (I'm making an assumption here based on every other response
time being much slower). Is there a way to configure the cluster so all
queries go to the master and only get routed to the non-master (further
away, less performant) if there's a failure on the master?
The cluster state API gives a full breakdown of where shards are located on
(or use elasticsearch-head). Is that what you are after?
On Tue, Mar 20, 2012 at 4:46 AM, Shane Witbeck shane@digitalsanctum.comwrote:
What's the best way to determine which nodes/shards search requests are
routed to? I'm experimenting with cluster.routing.allocation attributes.On Sunday, January 29, 2012 1:22:29 PM UTC-5, kimchy wrote:
The elected master node is not related to where queries are routed. Same
for elected primary shards. Searches are round robin between shard copies.
You can control it by using shard allocation awareness (which will come
handy when you have more nodes in the cluster to make sure copies of the
shards are allocated properly across the two zones) which will also make
sure that requests will go first to shards in their own zone. More info
here: http://www.Elasticsearch Platform — Find real-time answers at scale | Elastic
reference/modules/cluster.htmlhttp://www.elasticsearch.org/guide/reference/modules/cluster.html
**.On Saturday, January 28, 2012 at 2:43 AM, Shane Witbeck wrote:
I have 2 boxes in a cluster that are geographically diverse (one on east
coast and one on west coast). The behavior I observe is that it does a
round robin (I'm making an assumption here based on every other response
time being much slower). Is there a way to configure the cluster so all
queries go to the master and only get routed to the non-master (further
away, less performant) if there's a failure on the master?
Not exactly, I'd like to be able to audit which nodes and/or shards search
results are coming from.
While debugging I found the SearchResponse, which has getSuccessfulShards
and getShardFailures methods. I think these will give me what I'm looking
for.
Thanks.
On Tuesday, March 20, 2012 6:59:32 AM UTC-4, kimchy wrote:
The cluster state API gives a full breakdown of where shards are located
on (or use elasticsearch-head). Is that what you are after?On Tue, Mar 20, 2012 at 4:46 AM, Shane Witbeck wrote:
What's the best way to determine which nodes/shards search requests are
routed to? I'm experimenting with cluster.routing.allocation attributes.On Sunday, January 29, 2012 1:22:29 PM UTC-5, kimchy wrote:
The elected master node is not related to where queries are routed. Same
for elected primary shards. Searches are round robin between shard copies.
You can control it by using shard allocation awareness (which will come
handy when you have more nodes in the cluster to make sure copies of the
shards are allocated properly across the two zones) which will also make
sure that requests will go first to shards in their own zone. More info
here: http://www.Elasticsearch Platform — Find real-time answers at scale | Elastic
reference/modules/cluster.htmlhttp://www.elasticsearch.org/guide/reference/modules/cluster.html
**.On Saturday, January 28, 2012 at 2:43 AM, Shane Witbeck wrote:
I have 2 boxes in a cluster that are geographically diverse (one on east
coast and one on west coast). The behavior I observe is that it does a
round robin (I'm making an assumption here based on every other response
time being much slower). Is there a way to configure the cluster so all
queries go to the master and only get routed to the non-master (further
away, less performant) if there's a failure on the master?
If you set explain to true, you will also get as part of the search results
(SearchHit) the shard and node it came from. Though not possibly all the
shards/nodes the search executed on. Note, explain can be expensive, as it
provides other information as well.
On Tue, Mar 20, 2012 at 2:13 PM, Shane Witbeck shane@digitalsanctum.comwrote:
Not exactly, I'd like to be able to audit which nodes and/or shards search
results are coming from.While debugging I found the SearchResponse, which has getSuccessfulShards
and getShardFailures methods. I think these will give me what I'm looking
for.Thanks.
On Tuesday, March 20, 2012 6:59:32 AM UTC-4, kimchy wrote:
The cluster state API gives a full breakdown of where shards are located
on (or use elasticsearch-head). Is that what you are after?On Tue, Mar 20, 2012 at 4:46 AM, Shane Witbeck wrote:
What's the best way to determine which nodes/shards search requests are
routed to? I'm experimenting with cluster.routing.allocation attributes.On Sunday, January 29, 2012 1:22:29 PM UTC-5, kimchy wrote:
The elected master node is not related to where queries are routed.
Same for elected primary shards. Searches are round robin between shard
copies. You can control it by using shard allocation awareness (which will
come handy when you have more nodes in the cluster to make sure copies of
the shards are allocated properly across the two zones) which will also
make sure that requests will go first to shards in their own zone. More
info here: http://www.elasticsearch.org/guide/*reference/modules/
*cluster.htmlhttp://www.elasticsearch.org/guide/reference/modules/cluster.html
**.On Saturday, January 28, 2012 at 2:43 AM, Shane Witbeck wrote:
I have 2 boxes in a cluster that are geographically diverse (one on
east coast and one on west coast). The behavior I observe is that it does a
round robin (I'm making an assumption here based on every other response
time being much slower). Is there a way to configure the cluster so all
queries go to the master and only get routed to the non-master (further
away, less performant) if there's a failure on the master?