[
https://issues.apache.org/jira/browse/SOLR-11985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520669#comment-16520669
]
Jerry Bao commented on SOLR-11985:
----------------------------------
Given the way it was written, the concern I had was the following:
One collection has shards with 3 replicas and another collection has shards
with 4 replicas. If I had the following set of rules...
{code}
{"replica" : "<33%", "shard" : "#EACH", "sysprop:region": "us-east-1a"}
{"replica" : "<33%", "shard" : "#EACH", "sysprop:region": "us-east-1b"}
{"replica" : "<33%", "shard" : "#EACH", "sysprop:region": "us-east-1c"}
{code}
My concern was it would turn into
{code}
{"replica" : "<2", "shard" : "#EACH", "sysprop:region": "us-east-1a"}
{"replica" : "<2", "shard" : "#EACH", "sysprop:region": "us-east-1b"}
{"replica" : "<2", "shard" : "#EACH", "sysprop:region": "us-east-1c"}
{code}
for the collection with 3 replicas, and
{code}
{"replica" : "<3", "shard" : "#EACH", "sysprop:region": "us-east-1a"}
{"replica" : "<3", "shard" : "#EACH", "sysprop:region": "us-east-1b"}
{"replica" : "<3", "shard" : "#EACH", "sysprop:region": "us-east-1c"}
{code}
for the collection with 4 replicas. In the collection with 4 replicas, you
could have 2 replicas on us-east-1a and 2 replicas on us-east-1b. What we
really want is 1 on each before having the 4th replica on another zone. Due to
the way the rules are set up, it treats them individually when they should be
treated together; evenly balancing the replicas based on the number of zones
available.
We could make it work by making different zone rules per collection, but that
shouldn't be necessary. Rack awareness (which is what we're trying to achieve
here), should be collection agnostic and apply against each collection.
https://issues.apache.org/jira/browse/SOLR-12511 would help here.
> Allow percentage in replica attribute in policy
> -----------------------------------------------
>
> Key: SOLR-11985
> URL: https://issues.apache.org/jira/browse/SOLR-11985
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling, SolrCloud
> Reporter: Shalin Shekhar Mangar
> Assignee: Noble Paul
> Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-11985.patch, SOLR-11985.patch
>
>
> Today we can only specify an absolute number in the 'replica' attribute in
> the policy rules. It'd be useful to write a percentage value to make certain
> use-cases easier. For example:
> {code:java}
> // Keep a third of the the replicas of each shard in east region
> {"replica" : "<34%", "shard" : "#EACH", "sysprop:region": "east"}
> // Keep two thirds of the the replicas of each shard in west region
> {"replica" : "<67%", "shard" : "#EACH", "sysprop:region": "west"}
> {code}
> Today the above must be represented by different rules for each collection if
> they have different replication factors. Also if the replication factor
> changes later, the absolute value has to be changed in tandem. So expressing
> a percentage removes both of these restrictions.
> This feature means that the value of the attribute {{"replica"}} is only
> available just in time. We call such values {{"computed values"}} . The
> computed value for this attribute depends on other attributes as well.
> Take the following 2 rules
> {code:java}
> //example 1
> {"replica" : "<34%", "shard" : "#EACH", "sysprop:region": "east"}
> //example 2
> {"replica" : "<34%", "sysprop:region": "east"}
> {code}
> assume we have collection {{"A"}} with 2 shards and {{replicationFactor=3}}
> *example 1* would mean that the value of replica is computed as
> {{3 * 34 / 100 = 1.02}}
> Which means *_for each shard_* keep less than 1.02 replica in east
> availability zone
>
> *example 2* would mean that the value of replica is computed as
> {{3 * 2 * 34 / 100 = 2.04}}
>
> which means _*for each collection*_ keep less than 2.04 replicas on east
> availability zone
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
