Got it. The problem is tiebreakers. Consider two documents with the same date. Whenever two documents are tied through all the sort criteria you specify then the _internal_ Lucene document ID is used as a tiebreaker.
The kicker is that doc1 and doc2 don't have the same internal IDs on replica1 and replica2. In fact there is no guarantee that doc1 even has the same relationship to doc2 on the two replicas. That is, if internal_id_doc1 < internal_id_doc2 on replica 1 its quite possible that internal_id_doc1 > internal_id_doc2 on replica2. This has to do with segment merging and the fact that the segments are all merged locally, there's no coordination between replicas. So adding the secondary sort by ID is the usual way to handle this, so you're on the right track. Best, Erick On Fri, Dec 2, 2016 at 7:56 AM, Halim Chaibi <halim.cha...@gmail.com> wrote: > I think it's related to the sort clause: sort=position_posted_date_id, this > is happening only when documents have the same position_posted_date_id, I am > not sure what would be the default sort in this case, but depending on which > shards is handling the request, I am getting same result but sorted > differently. > > When adding a second sort by id like this > sort=position_posted_date_id%20desc,id%20desc, the issue is no longer > happening. > > Thanks > > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/Pagination-issue-tp4308226p4308310.html > Sent from the Solr - User mailing list archive at Nabble.com.
