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

Ayon Sinha commented on SOLR-8225:
----------------------------------

Can a recovering replica after a hiccup behave like recovery after "add 
replica"? Or is it already the same mechanism? What are the downsides of leader 
sending updates to only active replicas and the recovering can catch-up as and 
when they can.

Usually replicas will go into recovery due to one of the following common 
reasons:
1. GC pause
2. brief Network outage 

> Leader should send update requests to replicas in recovery asynchronously
> -------------------------------------------------------------------------
>
>                 Key: SOLR-8225
>                 URL: https://issues.apache.org/jira/browse/SOLR-8225
>             Project: Solr
>          Issue Type: Improvement
>          Components: SolrCloud
>            Reporter: Timothy Potter
>
> When a replica goes into recovery, the leader still sends docs to that 
> replica while it is recovering. What I'm seeing is that the recovering node 
> is still slow to respond to the leader (at least slower than the healthy 
> replicas). Thus it would be good if the leader could send the updates to the 
> recovering replica asynchronously, i.e. the leader will block as it does 
> today when forwarding updates to healthy / active replicas, but send updates 
> to recovering replicas async, thus preventing the whole update request from 
> being slowed down by a potentially degraded.
> FWIW - I've actually seen this occur in an environment that has more than 3 
> replicas per shard. One of the replicas went into recovery and then was much 
> slower to handle requests than the healthy replicas, but the leader had to 
> wait for the slowest replica.



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

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to