lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <>
Subject [jira] [Commented] (SOLR-4260) Inconsistent numDocs between leader and replica
Date Mon, 23 Dec 2013 23:14:52 GMT


Mark Miller commented on SOLR-4260:

Yeah, that's currently expected. We don't expect the case where you can talk to ZooKeeper
but not your replicas to be common, so we kind of punted on this scenario for the first phase.

Some related JIRA issues:


I think we should do all that, but the key is really, in this case, we need to pass the order
to recover through ZooKeeper to the partitioned off replica. With an eventually consistent
model, it can be off for a short time, but it needs to recover in a timely manner.

I think this is the right solution because the replica is sure to either get the information
to recover from ZooKeeper or lose it's connection to ZooKeeper in which case it will have
to recover anyway.

> Inconsistent numDocs between leader and replica
> -----------------------------------------------
>                 Key: SOLR-4260
>                 URL:
>             Project: Solr
>          Issue Type: Bug
>          Components: SolrCloud
>         Environment:
>            Reporter: Markus Jelsma
>            Assignee: Mark Miller
>            Priority: Critical
>             Fix For: 5.0, 4.7
>         Attachments:,, clusterstate.png
> After wiping all cores and reindexing some 3.3 million docs from Nutch using CloudSolrServer
we see inconsistencies between the leader and replica for some shards.
> Each core hold about 3.3k documents. For some reason 5 out of 10 shards have a small
deviation in then number of documents. The leader and slave deviate for roughly 10-20 documents,
not more.
> Results hopping ranks in the result set for identical queries got my attention, there
were small IDF differences for exactly the same record causing a record to shift positions
in the result set. During those tests no records were indexed. Consecutive catch all queries
also return different number of numDocs.
> We're running a 10 node test cluster with 10 shards and a replication factor of two and
frequently reindex using a fresh build from trunk. I've not seen this issue for quite some
time until a few days ago.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message