[ https://issues.apache.org/jira/browse/SOLR-6513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14189118#comment-14189118 ]
Jan Høydahl commented on SOLR-6513: ----------------------------------- I thought we agreed to prefer the term "shard" over "slice", so I think we should do this for this API as well. The *only* place in our refguide we use the word "slice" is in [How SolrCloud Works|https://cwiki.apache.org/confluence/display/solr/How+SolrCloud+Works] \[1\] and that description is disputed. The refguide explanation of what a shard is can be found in [Shards and Indexing Data in SolrCloud|https://cwiki.apache.org/confluence/display/solr/Shards+and+Indexing+Data+in+SolrCloud] \[2\], quoting: {quote} When your data is too large for one node, you can break it up and store it in sections by creating one or more shards. Each is a portion of the logical index, or core, and it's the set of all nodes containing that section of the index. {quote} So I'm proposing a rename of this API to {{BALANCESHARDUNIQUE}} and a rewrite of \[1\]. \[1\] https://cwiki.apache.org/confluence/display/solr/How+SolrCloud+Works \[2\] https://cwiki.apache.org/confluence/display/solr/Shards+and+Indexing+Data+in+SolrCloud > 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