[
https://issues.apache.org/jira/browse/SOLR-8227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14994535#comment-14994535
]
Sandeep J commented on SOLR-8227:
---------------------------------
We are using 4.10.3 in our production environment and I have been working to
patch it up for our solr environment. I have fix checked in at
https://github.com/sjangra-git/lucene-solr. I will create a patch file and
attach it on this ticket for review.
This is the logic that has been tried in this fix:
1. At the recovery time, we get the list of active replicas (including the
leader) from the cluster state.
2. This list of active replicas is shuffled.
3. Pick the first node from the shuffled list.
4. If the replica node selected in #3 is the same as the current recovering
node then continue with step #1
5. Else, select the replica and try recovery from it.
The only thing that changed is that instead of picking the leader always for
recovery, we randomly pick one active replica for recovery.
> 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]
