[
https://issues.apache.org/jira/browse/SOLR-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15409495#comment-15409495
]
Varun Thacker commented on SOLR-9369:
-------------------------------------
Here is a scenario where in SolrCloud this would help short-circuit replication
slightly faster
Assuming we have 1 shard , 2 replicas - replica 1 being the leader and replica2
being the follower
1. Index s few documents
2. Replica2 goes down
3. Index more than 100 documents - ( PeerSync default )
4. Replica2 comes up and ends up doing a full replication
5. Replica2 does down
6. Replica2 comes up
In step 6, if we have the 'commitTimeMSec' then solr short-circuits saying both
indexes are in sync.
If we were to remove 'commitTimeMSec' , then the replica has to download the
file list from the leader and be able to say that its in sync. So it would save
one step in this case.
But this would be rare as indexes generally aren't static
> SolrCloud should not compare commitTimeMSec to see if replicas are in sync
> --------------------------------------------------------------------------
>
> Key: SOLR-9369
> URL: https://issues.apache.org/jira/browse/SOLR-9369
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Varun Thacker
>
> Today the replication code we compare if two replicas are in sync by checking
> the commit timestamp ( "commitTimeMSec" )
> This made sense for master slave but I don't think is useful for SolrCloud
> since different replicas will commit at different times. We should not check
> for this in SolrCloud mode.
> Ramkumar noted this on SOLR-7859 as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
