Hi Savva I presume you're using cluster.routing.allocation.awareness? If so, then shards on nodes with the same node attributes are preferred:
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-cluster.html#_automatic_preference_when_searching_geting On 14 May 2014 19:28, [email protected] <[email protected]> wrote: > Only nodes that hold a shard (primary or replica) of an index you > specified participate in handling queries. Replica are selected by > round-robin afaik (or maybe at random order?). Which nodes are selected by > a query is determined at once by the node that receives the query within > the cluster. It is the node the TransportClient is connected to, because > the TransportClient is not able to keep a copy of the cluster state. This > proxy node also collects the results from the shards and builds the > response. There is no forwarding or redirecting from one node to another > after the proxy node has dispatched the query down to the shard level. > > Jörg > > > On Wed, May 14, 2014 at 7:11 PM, Savva <[email protected]> wrote: > >> Hi, >> >> I have a question regarding the query routing inside of a cluster. Let >> say, node holds full data replication and can satisfy every search request >> it receives. Will it redirect/reroute queries to other nodes in the cluster >> in case of a high load? >> >> The motivation is the following: I have 3 nodes distributed across >> availability zones; 10 indices with 1 shard and 2 replicas each. >> >> Now, in each zone there is a group of machines that connects to the node >> in the same zone via the transport client. Sniffing is turned off so as to >> reduce network latency and avoid requests from the clients to nodes across >> the zones. >> >> I'm wondering if nodes may redirect (for some reason) queries to other >> nodes in the cluster, even if they contain all necessary information for >> every request. >> >> If this is the case, is there any way to avoid such behavior, cause it >> produces additional hops that affect search time? >> >> Thank you, >> Savva >> >> -- >> You received this message because you are subscribed to the Google Groups >> "elasticsearch" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elasticsearch/2fe2dc69-6878-4525-8754-d409ef56df8d%40googlegroups.com >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/CAKdsXoF%3DDS-US5nguySRYqMw1tVo%3DucbohSLmPH6woMxTHLNtw%40mail.gmail.com<https://groups.google.com/d/msgid/elasticsearch/CAKdsXoF%3DDS-US5nguySRYqMw1tVo%3DucbohSLmPH6woMxTHLNtw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAPt3XKS6D1PX060uRiVFePNCoRzEQbgzFhwLk-JKkq3nBp6SQQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
