You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by CONAN <pe...@163.com> on 2014/06/27 04:47:41 UTC

numFound is changing when start parameter changed

hi
I use solr4.4 , 2 shards and 2 replicas  and I found a problem on solrCloud search.


If I perform a query  with start=0 and rows=10 and say fq=ownerId:123 , I get numFound=225.
If I simply change the start param to start=6, I get numFound=223.
and i change the start param to start=10 , i get numFound=219.


i searhed google and get "You probably have duplicates (docs on different shards with the same id)."


how is that happen? is that a bug? and how to fix it? 
Thanks




-Conan















Re: numFound is changing when start parameter changed

Posted by Shawn Heisey <so...@elyograg.org>.
On 6/26/2014 8:47 PM, CONAN wrote:
> I use solr4.4 , 2 shards and 2 replicas  and I found a problem on solrCloud search.
>
>
> If I perform a query  with start=0 and rows=10 and say fq=ownerId:123 , I get numFound=225.
> If I simply change the start param to start=6, I get numFound=223.
> and i change the start param to start=10 , i get numFound=219.
>
>
> i searhed google and get "You probably have duplicates (docs on different shards with the same id)."
>
>
> how is that happen? is that a bug? and how to fix it? 

I think you mentioned this problem on IRC as well.

What is the "router" on your collection?  Is it implicit, or something
like compositeId?  You can find this by opening the admin UI, clicking
Cloud, then Tree, and finding your collection under /collections.  Click
on the collection and look on the right side for the "router" entry.

If you have implicit routing or you are using some other method (such as
shard keys) to determine which shard contains a given document ID, then
this problem would happen because you or your indexing program sent the
same ID to different shards.

If you're using compositeId so that document routing is automatic, then
it should be impossible for this to happen ... unless you have manually
adjusted your clusterstate and changed the hash ranges.

Thanks,
Shawn