You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "David Smiley (Jira)" <ji...@apache.org> on 2022/10/14 05:15:00 UTC
[jira] [Commented] (SOLR-12767) Deprecate min_rf parameter and always include the achieved rf in the response
[ https://issues.apache.org/jira/browse/SOLR-12767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17617475#comment-17617475 ]
David Smiley commented on SOLR-12767:
-------------------------------------
Note that there is a conundrum if the leader is more up to date than its only non-leader replica, and then the leader goes down indefinitely. You're kinda screwed from an indexing availability perspective, since the other replica knows it doesn't have the highest ZkShardTerm and thus isn't leader-eligible. You haven't lost "consistency" but you've lost "availability" (to indexing). The indexing client can choose to examine the "rf" == 1 of the response, and consider it a failure, but until the leader comes back, only operator intervention of a "FORCELEADER" command would restore indexing. Had min_rf stayed as a feature, I'd argue it would be a way for Solr to know that this update "doesn't count" if it's unable to satisfy min_rf, and thus don't mess with ZkShardTerms. Any way; this is a bit theoretical; it's not something I've run into.
> Deprecate min_rf parameter and always include the achieved rf in the response
> -----------------------------------------------------------------------------
>
> Key: SOLR-12767
> URL: https://issues.apache.org/jira/browse/SOLR-12767
> Project: Solr
> Issue Type: Improvement
> Reporter: Tomas Eduardo Fernandez Lobbe
> Assignee: Tomas Eduardo Fernandez Lobbe
> Priority: Major
> Fix For: 7.6
>
> Attachments: SOLR-12767.patch, SOLR-12767.patch, SOLR-12767.patch, SOLR-12767.patch, SOLR-12767.patch, SOLR-12767.patch
>
>
> Currently the {{min_rf}} parameter does two things.
> 1. It tells Solr that the user wants to keep track of the achieved replication factor
> 2. (undocumented AFAICT) It prevents Solr from putting replicas in recovery if the achieved replication factor is lower than the {{min_rf}} specified
> #2 is intentional and I believe the reason behind it is to prevent replicas to go into recovery in cases of short hiccups (since the assumption is that the user is going to retry the request anyway). This is dangerous because if the user doesn’t retry (or retries a number of times but keeps failing) the replicas will be permanently inconsistent. Also, since we now retry updates from leaders to replicas, this behavior has less value, since short temporary blips should be recovered by those retries anyway.
> I think we should remove the behavior described in #2, #1 is still valuable, but there isn’t much point of making the parameter an integer, the user is just telling Solr that they want the achieved replication factor, so it could be a boolean, but I’m thinking we probably don’t even want to expose the parameter, and just always keep track of it, and include it in the response. It’s not costly to calculate, so why keep two separate code paths?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org