[ 
https://issues.apache.org/jira/browse/SOLR-12495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16521323#comment-16521323
 ] 

Jerry Bao commented on SOLR-12495:
----------------------------------

{quote}
Is there anything that's not already addressed by that? I understand that it 
won't show any violations if you are already in an imbalanced state.
{quote}

Thats the main issue: no violations if you're already in an imbalanced state. 
If the autoscaling suggestions also suggested to move replicas to a more 
balanced state (based on the preferences) without any violations, then that 
would solve this issue. 

We have machines that have 0 load on them because the collections are 
distributed amongst the machines but all of the replicas aren't distributed. We 
also see machines with too much load because they have one of every 
collection's replica on it.

{quote}
This can always lead to violations which are impossible to satisfy
{quote}

I think this can lead to violations that are impossible to satisfy because 
often to fix the violation, it takes multiple steps. Something like, doing a 
3-way triangle movement. I understand that the more movement possible, the 
exponential increase in combinations you have to check, but I think we can be 
smarter here about deciding which machines are definitely possible to move to 
and which doesn't make sense to move to.

I would say that if we could incorporate the preferences into suggestions (so 
that the trigger can move things to be more balanced based on our preferences), 
that should help us a lot here.

> Enhance the Autoscaling policy syntax to evenly distribute replicas
> -------------------------------------------------------------------
>
>                 Key: SOLR-12495
>                 URL: https://issues.apache.org/jira/browse/SOLR-12495
>             Project: Solr
>          Issue Type: New Feature
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: AutoScaling
>            Reporter: Noble Paul
>            Priority: Major
>
> Support a new function value for {{replica= "#MINIMUM"}}
> {{#MINIMUM}} means the minimum computed value for the given configuration
> the value of replica will be calculated as  {{<= 
> Math.ceil(number_of_replicas/number_of_valid_nodes) }}
> *example 1:*
> {code:java}
> {"replica" : "#MINIMUM" , "shard" : "#EACH" , "node" : "#ANY"}
> {code}
> *case 1* : nodes=3, replicationFactor=4
>  the value of replica will be calculated as {{Math.ceil(4/3) = 2}}
> current state : nodes=3, replicationFactor=2
> this is equivalent to the hard coded rule
> {code:java}
> {"replica" : "<3" , "shard" : "#EACH" , "node" : "#ANY"}
> {code}
> *case 2* : 
> current state : nodes=3, replicationFactor=2
> this is equivalent to the hard coded rule
> {code:java}
> {"replica" : "<3" , "shard" : "#EACH" , "node" : "#ANY"}
> {code}
> *example:2*
> {code}
> {"replica" : "#MINIMUM"  , "node" : "#ANY"}{code}
> case 1: numShards = 2, replicationFactor=3, nodes = 5
> this is equivalent to the hard coded rule
> {code:java}
> {"replica" : "<3" , "node" : "#ANY"}
> {code}
> *example:3*
> {code}
> {"replica" : "<2"  , "shard" : "#EACH" , "port" : "8983"}{code}
> case 1: {{replicationFactor=3, nodes with port 8983 = 2}}
> this is equivalent to the hard coded rule
> {code}
> {"replica" : "<3"  , "shard" : "#EACH" , "port" : "8983"}{code}



--
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

Reply via email to