[
https://issues.apache.org/jira/browse/SOLR-8225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15000659#comment-15000659
]
Mark Miller commented on SOLR-8225:
-----------------------------------
bq. but the leader had to wait for the slowest replica.
To some degree, you could mitigate this with the min replication factor on
updates right? I don't know how it is now, but in an ideal world, we could
return once we got the n fastest responses.
> 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]
