You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Jeff Courtade <co...@gmail.com> on 2015/08/19 15:52:55 UTC
Solr leader and replica version mismatch 4.7.2
We are running SOLR 4.7.2
SolrCloud with 2 shards
one Leader and one replica per shard.
the "Version" of the replica and leader differ displayed here as...
curl http://ps01:8983/solr/admin/cores?action=STATUS |sed 's/></>\n</g'
<long name="version">7753045</long>
However the commitTimeMSec lastModified and sizeInBytes matches on Leader
and replica
curl http://ps01:8983/solr/admin/cores?action=STATUS |sed 's/></>\n</g'
<str name="commitTimeMSec">1439974815928</str>
</lst>
<date name="lastModified">2015-08-19T09:00:15.928Z</date>
<long name="sizeInBytes">43691759309</long>
<str name="size">40.69 GB</str>
if that number date and size match on the leader and the replicas I believe
we are in sync.
Can anyone verify this?
--
Thanks,
Jeff Courtade
M: 240.507.6116
Re: Solr leader and replica version mismatch 4.7.2
Posted by Jeff Courtade <co...@gmail.com>.
What I am trying to determine is a way to validate for instance if a leader
dies. As in completely unrecoverable that the data on the replica is an
exact match to what the leader had.
I need to be able to monitor it and have confidence that it is working as
expected.
i had assumed the version number is what I was interested in.
Should the version number be different in SOLR Cloud then as it is
deprecated?
--
Thanks,
Jeff Courtade
M: 240.507.6116
On Wed, Aug 19, 2015 at 10:08 AM, Shawn Heisey <ap...@elyograg.org> wrote:
> On 8/19/2015 7:52 AM, Jeff Courtade wrote:
> > We are running SOLR 4.7.2
> > SolrCloud with 2 shards
> > one Leader and one replica per shard.
> >
> > the "Version" of the replica and leader differ displayed here as...
> >
> > curl http://ps01:8983/solr/admin/cores?action=STATUS |sed 's/></>\n</g'
> >
> > <long name="version">7753045</long>
> >
> >
> > However the commitTimeMSec lastModified and sizeInBytes matches on Leader
> > and replica
>
> SolrCloud works very differently than the old master-slave replication.
> The index is NOT copied from the leader to the other replicas, except
> in extreme recovery circumstances.
>
> Each replica builds its own copy of the index independently from the
> others. Due to slight timing differences in the indexing operations,
> and possible actions related to transaction log replay on node restart,
> each replica may end up with a different index layout. There also could
> be differences in the number of deleted documents. Unless something
> goes really wrong, all replicas should contain the same live documents.
>
> Thanks,
> Shawn
>
>
Re: Solr leader and replica version mismatch 4.7.2
Posted by Shawn Heisey <ap...@elyograg.org>.
On 8/19/2015 7:52 AM, Jeff Courtade wrote:
> We are running SOLR 4.7.2
> SolrCloud with 2 shards
> one Leader and one replica per shard.
>
> the "Version" of the replica and leader differ displayed here as...
>
> curl http://ps01:8983/solr/admin/cores?action=STATUS |sed 's/></>\n</g'
>
> <long name="version">7753045</long>
>
>
> However the commitTimeMSec lastModified and sizeInBytes matches on Leader
> and replica
SolrCloud works very differently than the old master-slave replication.
The index is NOT copied from the leader to the other replicas, except
in extreme recovery circumstances.
Each replica builds its own copy of the index independently from the
others. Due to slight timing differences in the indexing operations,
and possible actions related to transaction log replay on node restart,
each replica may end up with a different index layout. There also could
be differences in the number of deleted documents. Unless something
goes really wrong, all replicas should contain the same live documents.
Thanks,
Shawn