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

Erick Erickson commented on SOLR-6513:
--------------------------------------

Still, I'm all for keeping things consistent. See SOLR-6670 and we'll go from 
there.

> Add a collectionsAPI call BALANCESLICEUNIQUE
> --------------------------------------------
>
>                 Key: SOLR-6513
>                 URL: https://issues.apache.org/jira/browse/SOLR-6513
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Erick Erickson
>            Assignee: Erick Erickson
>             Fix For: 5.0, Trunk
>
>         Attachments: SOLR-6513.patch, SOLR-6513.patch, SOLR-6513.patch, 
> SOLR-6513.patch
>
>
> Another sub-task for SOLR-6491. The ability to assign a property on a 
> node-by-node basis is nice, but tedious to get right for a sysadmin, 
> especially if there are, say, 100s of nodes hosting a system. This JIRA would 
> essentially provide an automatic mechanism for assigning a property. This 
> particular command simply changes the cluster state, it doesn't do anything 
> like re-assign functions.
> My idea for this version is fairly limited. You'd have to specify a 
> collection and there would be no attempt to, say, evenly distribute the 
> preferred leader role/property for this collection by looking at _other_ 
> collections. Or by looking at underlying hardware capabilities. Or....
> It would be a pretty simple round-robin assignment. About the only 
> intelligence built in would be to change as few roles/properties as possible. 
> Let's say that the correct number of nodes for this role turned out to be 3. 
> Any node currently having 3 properties for this collection would NOT be 
> changed. Any node having 2 properties would have one added that would be 
> taken from some node with > 3 properties like this.
> This probably needs an optional parameter, something like 
> "includeInactiveNodes=true|false"
> Since this is an arbitrary property, one must specify sliceUnique=true. So 
> for the "preferredLeader" functionality, one would specify something like:
> action=BALANCESLICEUNIQUE&property=preferredLeader&proprety.value=true.
> There are checks in this code that require the preferredLeader to have a t/f 
> value and require that sliceUnique bet true. That said, this can be called on 
> an arbitrary property that has only one such property per slice.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to