You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2018/10/03 16:47:00 UTC
[jira] [Commented] (SOLR-8034) If minRF is not satisfied, leader
should not put replicas in recovery
[ https://issues.apache.org/jira/browse/SOLR-8034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16637181#comment-16637181 ]
ASF subversion and git services commented on SOLR-8034:
-------------------------------------------------------
Commit 46f753d7c6df52c06d970a13d3b742310276f2ca in lucene-solr's branch refs/heads/master from Tomas Fernandez Lobbe
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=46f753d ]
SOLR-12767: Always include the achieved rf in the response
This commit deprecates the min_rf parameter. Solr now always includes the achieved replication
factor in the update requests (as if min_rf was always specified). Also, reverts the changes
introduced in SOLR-8034, replicas that don't ack an update will have to recover to prevent
inconsistent shards.
> If minRF is not satisfied, leader should not put replicas in recovery
> ---------------------------------------------------------------------
>
> Key: SOLR-8034
> URL: https://issues.apache.org/jira/browse/SOLR-8034
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: Jessica Cheng Mallet
> Assignee: Anshum Gupta
> Priority: Major
> Labels: solrcloud
> Fix For: 5.4, 6.0
>
> Attachments: SOLR-8034.patch, SOLR-8034.patch
>
>
> If the minimum replication factor parameter (minRf) in a solr update request is not satisfied -- i.e. if the update was not successfully applied on at least n replicas where n >= minRf -- the shard leader should not put the failed replicas in "leader initiated recovery" and the client should retry the update instead.
> This is so that in the scenario were minRf is not satisfied, the failed replicas can still be eligible to become a leader in case of leader failure, since in the client's perspective this update did not succeed.
> This came up from a network partition scenario where the leader becomes sectioned off from its two followers, but they all could still talk to zookeeper. The partitioned leader set its two followers as in leader initiated recovery, so we couldn't just kill off the partitioned node and have a follower take over leadership. For a minRf=1 case, this is the correct behavior because the partitioned leader would have accepted updates that the followers don't have, and therefore we can't switch leadership or we'd lose those updates. However, in the case of minRf=2, solr never accepted any update in the client's point of view, so in fact the partitioned leader doesn't have any accepted update that the followers don't have, and therefore the followers should be eligible to become leaders. Thus, I'm proposing modifying the leader initiated recovery logic to not put the followers in recovery if the minRf parameter is present and is not satisfied.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org