Thanks shawn. In my organisation we also want to implement the solrcloud, but the problem is that, we are using the master-slave architecture and on master we do all indexing, architecture of master is lower than the slaves.
So if we implement the solrcloud in a fashion that master will be the leader, and slaves will be the replicas then in that case, in the case of high load leader can bear it, I guess every query firstly goes to leader then it distributes the request as i noticed from the logs and blogs :) As well as master is in NY and slaves are in Dallas, which also might cause latency issue and it will instead fail our purpose of faster query response. So i thought to use this shards parameter so that we query only from the replicas not to the leader so that leader just work fine. But we were not sure about this shards parameter, what do you think? what should we do with latency issue and shards parameter. With Regards Aman Tandon On Fri, Jun 6, 2014 at 7:24 PM, Shawn Heisey <s...@elyograg.org> wrote: > On 6/6/2014 6:25 AM, Aman Tandon wrote: > > Does this *shards* parameter will also work in near future with solr 5? > > I am not aware of any plan to deprecate or remove the shards parameter. > My personal experience is with versions from 1.4.0 through 4.7.2. It > works in all of those versions. Without SolrCloud, the shards parameter > is the only way you can do a distributed search. > > Thanks, > Shawn > >
