all of the "routing" logic (preferLocal, shards.preference, etc...) really only comes into play once solr "code" (either CloudSolrClient, or a solr server recieving a request) decides that it needs to make a remote connection.
If a node recieves a request, and it has a local core capable of handling that request, it will process it in order to avoid the network overhead of sending it somewhere else. Where things like shards.preference (and the deprecated "preferLocalShards") come into play (on the server side) is in situations where a Solr node is acting as a a Solr client: 1) the Solr node does't have any cores suitable for dealing with teh request (ie: it's a 'top level' request for a collection that has no local replicas and must be forwarded) 2) Solr is processing a top-level request and now needs to federate distributed sub-requests to each of the shards and is deciding which replica of each shard should get the request. : Date: Wed, 10 Mar 2021 18:42:35 +0100 : From: Jan Høydahl <jan....@cominvent.com> : Reply-To: users@solr.apache.org : To: users@solr.apache.org : Subject: Re: Solr not distributing search requests among replicas : : We have not set any shard.preference, and I also think preferLocal defaults to false, i.e random : : Earlier we had 2 shares for the same collection (both existed on both nodes) and then requests were distributed to both nodes. That’s why, when we went to 1 shard, I was wondering if the “single-shard” code path perhaps never attempts to utilize replicas?? But have not looked in code yet. : : Guess next step is to setup a small local test cluster and see what happens. : : Jan Høydahl : : > 10. mar. 2021 kl. 15:46 skrev Michael Gibney <mich...@michaelgibney.net>: : > : > You say not "anything fancy" -- depending on how you define "fancy", if you : > have an explicit `shards.preference` param, based on the version you're : > running (8.4) you might also take a look at : > https://issues.apache.org/jira/browse/SOLR-14471. (If SOLR-14471 is the : > problem, removing the explicit `shards.preference` param should restore : > default "shuffling" routing). : > : > I haven't dug too deep, but it looks like for 8.4 preferLocalShards : > actually defaults to false? I might be missing something though: : > https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.4.1/solr/solrj/src/java/org/apache/solr/client/solrj/routing/RequestReplicaListTransformerGenerator.java#L85 : > : > : > : >> On Wed, Mar 10, 2021 at 9:10 AM Houston Putman <houstonput...@gmail.com> : >> wrote: : >> : >> I could be wrong, but i dont think preferLocalShards is the default in : >> multi-shard use cases. : >> : >>> On Wed, Mar 10, 2021 at 9:07 AM Mike Drob <md...@mdrob.com> wrote: : >>> : >>> I believe a server will always try to prefer local cores. Can you do an : >>> experiment with 3 nodes, and send http queries to the node not hosting : >> any : >>> replicas? That should confirm the balanced distribution. : >>> : >>> If you have multiple shards, the receiving server will forward the : >> requests : >>> for shards it doesn’t have, but would still prefer local shards when they : >>> are available. : >>> : >>> On Wed, Mar 10, 2021 at 8:00 AM Jan Høydahl <jan....@cominvent.com> : >> wrote: : >>> : >>>> Hi, : >>>> : >>>> A client has a SolrCloud 8.4 setup with two nodes, and one collection : >>> with : >>>> one shard and replicationFactor=2. : >>>> Of course we want search traffic to be evenly distributed between the : >> two : >>>> replicas. : >>>> The client is using plain HTTP requests, no SolrJ or anything fancy, : >> and : >>>> sends all requests to one of the two nodes. : >>>> I was expecting Solr to forward about 50% of those requests to the : >> other : >>>> replica, but it is serving them all locally. : >>>> : >>>> I know we can setup an LB in front or re-program the client to do round : >>>> robin, but that is not my question. : >>>> Is the select-random-replica logic only active when we have a sharded : >>>> oollection, and not for a single-shard? : >>>> : >>>> Jan : >>> : >> : -Hoss http://www.lucidworks.com/
