[ https://issues.apache.org/jira/browse/SOLR-6513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14163617#comment-14163617 ]
ASF subversion and git services commented on SOLR-6513: ------------------------------------------------------- Commit 1630143 from [~erickoerickson] in branch 'dev/trunk' [ https://svn.apache.org/r1630143 ] SOLR-6513: Add a collectionsAPI call BALANCESLICEUNIQUE > 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 > 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