[
https://issues.apache.org/jira/browse/SOLR-8034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14741577#comment-14741577
]
Anshum Gupta commented on SOLR-8034:
------------------------------------
I'm kind of split on this as the replica here would be out of sync from the
leader and would never know about it, increasing the odds of inconsistency when
the client doesn't handle it the right way i.e. it kind of self-heals at this
point, and that would stop happening.
At the same time, I kind of like the idea as it allows for failover in the case
you've mentioned above.
For the patch, LGTM. Can you also test that the replica is down, right after
the first network partition, but before you send the document? That would
ensure that the replication factor is 2, because of the partition and not due
to another variable.
Also, can you fix the comment for assertion failure below? You're expecting 2
_non-leader_replicas and not 2 _replicas_:
{code}
+ List<Replica> notLeaders =
+ ensureAllReplicasAreActive(testCollectionName, "shard1", 1, 3,
maxWaitSecsToSeeAllActive);
+ assertTrue("Expected 2 replicas for collection " + testCollectionName
+ + " but found " + notLeaders.size() + "; clusterState: "
+ + printClusterStateInfo(testCollectionName),
+ notLeaders.size() == 2);
{code}
> 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: Bug
> Components: SolrCloud
> Reporter: Jessica Cheng Mallet
> Labels: solrcloud
> Attachments: 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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
