1) We have 1 core and we use the default search handler.
2) For the shards, we use the URL
parameters, shards=s1/solr,s2/solr,s3/solr,...,s8/solr
where s# point to a baremetal load balancer that routes the requests to
one of the two slave shards.
There is definitely the chance that on each page, the load balancer is
mixing the shards used for searching. Is there a possibility that the
Master1 may have two shards with two different counts? This could explain
it.
3) For the URL to execute the aggregating search, we have a virtual IP that
round robins to all 16 slaves in the cluster.
On a given search, any one of the 16 slaves may field the aggregation
request then the shard single-node queries are fired off to the load
balancer which then may mix up the nodes.
Other than the load balancing, we have no other configuration or search
differences besides the start parameter in the URL to move to the next page.
On Tue, Jun 19, 2012 at 4:20 PM, Yury Kats <yuryk...@yahoo.com> wrote:
> On 6/19/2012 4:06 PM, Justin Babuscio wrote:
> > Solr v3.5.0
> > 8 Master Shards
> > 2 Slaves Per Master
> >
> > Confirming that there are no active records being written, the "numFound"
> > value is decreasing as we page through the results.
> >
> > For example,
> > Page1 - numFound = 3683
> > Page2 - numFound = 3683
> > Page3 - numFound = 3683
> > Page4 - numFound = 2866
> > Page5 - numFound = 2419
> > Page5 - numFound = 1898
> > Page6 - numFound = 1898
> > ...
> > PageN - numFound = 1898
> >
> >
> >
> > It looks like it eventually settles on the real count. Is this a
> > limitation when using a distributed cluster or is the numFound always
> > intended to give an approximately similar to how Google responds with
> total
> > hits?
>
> numFound should return the real count for any given query.
> How are you sepcifying which shards/cores to use for each query?
> Does this change between queries?
>
>
--
Justin Babuscio
571-210-0035
http://linchpinsoftware.com
