[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
