You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Ishan Chattopadhyaya (JIRA)" <ji...@apache.org> on 2015/12/09 05:40:11 UTC

[jira] [Commented] (SOLR-8227) Recovering replicas should be able to recover from any active replica

    [ https://issues.apache.org/jira/browse/SOLR-8227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15048016#comment-15048016 ] 

Ishan Chattopadhyaya commented on SOLR-8227:
--------------------------------------------

It occurred to me, and I may be grossly misunderstanding the feasibility of doing this, that we might be able to make peer sync faster by:
# Get the list of updates to apply from leader
# But, fetch the independent updates from all the active replicas in parallel (and if a non-leader doesn't have a particular update, retry the leader with those).

This might save some cycles on the leader, and also parallel requests might help speed up the recovery of the replica.
Does this make any sense?

> Recovering replicas should be able to recover from any active replica
> ---------------------------------------------------------------------
>
>                 Key: SOLR-8227
>                 URL: https://issues.apache.org/jira/browse/SOLR-8227
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Varun Thacker
>
> Currently when a replica goes into recovery it uses the leader to recover. It first   tries to do a PeerSync. If thats not successful it does a replication. Most of the times it ends up doing a full replication because segment merging, autoCommits causing segments to be formed differently on the replicas ( We should explore improving that in another issue ) . 
> But when many replicas are recovering and hitting the leader, the leader can become a bottleneck. Since Solr is a CP system , we should be able to recover from any of the 'active' replicas instead of just the leader. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org