lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davide Isoardi <>
Subject R: Incongruent results of numdocs
Date Fri, 14 Oct 2016 15:50:23 GMT
thank you very much for the quick answare.

Yes, I am not indexing between request.

How can I risync two or all replicas?

If I look the overviews in the shard menu (attached the screenshot) I see that the num docs
are mismatched.

Davide Isoardi

eCube S.r.l.<>

Tel.  +390113999301

Mobile +393288204915

Fax. +390113999309

Informativa ai sensi del Decr.Lgs Privacy n.196/2003

ECUBE tratta i dati personali secondo quanto specificato nella pagina “Privacy Policy”
disponibile su Le informazioni contenute nel presente
messaggio sono destinate esclusivamente al/ai destinatario/i indicato/i. Qualora riceviate
il presente messaggio per errore, vi preghiamo di voler cortesemente darcene notizia via e-mail
(<>) e di provvedere ad eliminare il messaggio
ricevuto erroneamente, essendo illegittimo ed illecito ogni diverso utilizzo.

-----Messaggio originale-----

Da: Shawn Heisey []

Inviato: venerdì 14 ottobre 2016 14:32


Oggetto: Re: Incongruent results of numdocs

On 10/14/2016 3:35 AM, Davide Isoardi wrote:

> I have indexed more than 1 million of docs on a SolrCloud collections whit 5 shards and
2 replicas.


> After the indexing if I try to query (many times) q=id:*&rows=0 I have different
result for the document number founds.


> Why the result is not the same for all querys?

Assuming that you are not indexing new documents between requests, there are two reasons for
this problem:

1) You have documents with the same uniqueKey value in more than one of your shards.  This
typically happens when the router on the collection is set to "implicit" ... which basically
means "manual."

2) Your two replicas are out of sync, which might have any number of causes.

Side note:  "q=id:*" is a very inefficient query.  You would be better off with a range query
-- "q=id:[* TO *]".  That would be faster and use less memory.  If the id field is your uniqueKey,
then an even faster query and 100% equivalent query is the one for all docs -- "q=*:*".



  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message