[
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: [email protected]
For additional commands, e-mail: [email protected]
