[
https://issues.apache.org/jira/browse/SOLR-6606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14167353#comment-14167353
]
Shalin Shekhar Mangar commented on SOLR-6606:
---------------------------------------------
bq. I don't think whether it is guaranteed or not really matters. Just making
it much more common is certainly a worthwhile improvement.
+1
There are three problems that we can solve for faster recoveries (there might
be others):
# Replicas assign their own commit time stamp causing almost identical segments
to be downloaded again (which is solved by this issue)
# Segments merged away by leader that might still exist on an out-of-date
replica
# Single-threaded execution of transaction log replay (thanks Mark for pointing
this out to me sometime back)
Replicas can potentially ask other replicas too for segments with a particular
commit id thereby spreading the load away from the leader.
bq. Secondly is writing commits with the same meta 'commitTimeMSec' correct? Or
should change the ReplicationHandler 'fetchindex' logic to use the work done on
LUCENE-5895 instead?
I think both approaches are fine but if we go for the approach in LUCENE-5895
then we will need some careful back-compat logic in SnapPuller to make sure
that we don't force replicas to re-download existing segments just because we
started using another id.
> In cloud mode the leader should distribute autoCommits to it's replicas
> -----------------------------------------------------------------------
>
> Key: SOLR-6606
> URL: https://issues.apache.org/jira/browse/SOLR-6606
> Project: Solr
> Issue Type: Improvement
> Reporter: Varun Thacker
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6606.patch, SOLR-6606.patch
>
>
> Today in SolrCloud different replicas of a shard can trigger auto (hard)
> commits at different times. Although the documents which get added to the
> system remain consistent the way the segments gets formed can be different
> because of this.
> The downside of segments not getting formed in an identical fashion across
> replicas is that when a replica goes into recovery chances are that it has to
> do a full index replication from the leader. This is time consuming and we
> can possibly avoid this if the leader forwards auto (hard) commit commands to
> it's replicas and the replicas never explicitly trigger an auto (hard) commit.
> I am working on a patch. Should have it up shortly
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
