Re: Always use leader for searching queries

2018-01-09 Thread Novin Novin
Thank you very much for all your help. On Tue 9 Jan 2018, 16:32 Erick Erickson, wrote: > One thing to be aware of is that the commit points on the replicas in a > replica may (will) fire at different times. So when you're comparing the > number of docs on the replicas in a shard you have to comp

Re: Always use leader for searching queries

2018-01-09 Thread Erick Erickson
One thing to be aware of is that the commit points on the replicas in a replica may (will) fire at different times. So when you're comparing the number of docs on the replicas in a shard you have to compare before the last commit interval. So say you have a soft commit of 1 minute. When comparing t

Re: Always use leader for searching queries

2018-01-09 Thread Novin Novin
Hi Erick, Apology for delay. [This isn't what I meant. I meant to query each replica directly _within_ the same shard. Your problem statement is that the leader and replicas (I use "followers") have different document counts. How are you verifying this? Through the admin UI? Using &distrib=false

Re: Always use leader for searching queries

2018-01-03 Thread Walter Underwood
If you have a field for the indexed datetime, you can use a filter query to get rid of recent updates that might be in transit. I’d use double the autocommit time, to leave time for the followers to index. If the autocommit interval is one minute: fq=indexed_datetime:[* TO NOW-2MIN] wunder Wal

Re: Always use leader for searching queries

2018-01-03 Thread Erick Erickson
[I probably not need to do this because I have only one shard but I did anyway count was different.] This isn't what I meant. I meant to query each replica directly _within_ the same shard. Your problem statement is that the leader and replicas (I use "followers") have different document counts. H

Re: Always use leader for searching queries

2018-01-03 Thread Novin Novin
Hi Erick, Thanks for your reply. [ First of all, replicas can be off in terms of counts for the soft commit interval. The commits don't all happen on the replicas at the same wall-clock time. Solr promises eventual consistency, in this case NOW-autocommit time.] I realized that, to stop it. I ha

Re: Always use leader for searching queries

2018-01-02 Thread Erick Erickson
First of all, replicas can be off in terms of counts for the soft commit interval. The commits don't all happen on the replicas at the same wall-clock time. Solr promises eventual consistency, in this case NOW-autocommit time. So my first question is whether the replicas in the shard are inconsist

Re: Always use leader for searching queries

2018-01-02 Thread Novin Novin
Hi Erick, You are right, it is XY Problem. Allow me to explain best I can, I have two replica of one collection called "Main". When I was using search feature in my application I get two different numFound count. So I start digging after spending 2 3 hours I found the one replica has numFound cou

Re: Always use leader for searching queries

2018-01-02 Thread Erick Erickson
This seems like an XY problem. You're asking how to do X because you think it will solve problem Y without telling us what Y is. I say this because on the surface this seems to defeat the purpose behind SolrCloud. Why would you want to only make use of one piece of hardware? That will limit your t