Hi Shawn, Thanks for your reply.
We did some tests enabling shards.info=true and confirmed that there is not duplicate copy of our index. We have one replica but many times we see three versions on Admin GUI/Overview tab. All three has different versions and gen. Is that a problem? Master (Searching) Master (Replicable) Slave (Searching) We constantly see max searcher open exception. The warmup time is 1.5 minutes but the difference between openedAt date and registeredAt date is at times more than 4-5 minutes. Is the true searcher time the difference between two dates and not the warmupTime? openedAt: 2014-08-28T16:17:24.829Z registeredAt: 2014-08-28T16:21:02.278Z warmupTime: 65727 Thanks for all help. -----Original Message----- From: Shawn Heisey [mailto:s...@elyograg.org] Sent: Wednesday, August 27, 2014 2:37 PM To: solr-user@lucene.apache.org Subject: Re: solr query gives different numFound upon refreshing On 8/27/2014 10:44 AM, Bryan Bende wrote: > Theoretically this shouldn't happen, but is it possible that the two > replicas for a given shard are not fully in sync? > > Say shard1 replica1 is missing a document that is in shard1 replica2... if > you run a query that would hit on that document and run it a bunch of > times, sometimes replica 1 will handle the request and sometimes replica 2 > will handle it, and it would change your number of results if one of them > is missing a document. You could write a program that compares each > replica's documents by querying them with distrib=false. > > If there was a replica out of sync, I would think it would detect that on a > restart when comparing itself against the leader for that shard, but I'm > not sure. A replica out of sync is a possibility, but the most common reason for a changing numFound is because the overall distributed index has more than one document with the same uniqueKey value -- different versions of the same document in more than one shard. SolrCloud tries really hard to never end up with replicas out of sync, but either due to highly unusual circumstances or bugs, it could still happen. Thanks, Shawn
