Tomás Fernández Löbbe created SOLR-12767:
--------------------------------------------
Summary: Deprecate min_rf
Key: SOLR-12767
URL: https://issues.apache.org/jira/browse/SOLR-12767
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Tomás Fernández Löbbe
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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
