You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Erick Erickson (JIRA)" <ji...@apache.org> on 2014/09/14 00:49:33 UTC

[jira] [Commented] (SOLR-6513) Add a collectionsAPI call ASSIGNPREFERREDLEADERS

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

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

It'd probably also be good to add something to the shard when getting the clusterstatus, something akin to:

"preferredLeaders assigned/actual":"32/30"

that would represent the congruence (or lack thereof) of the model and reality.

> Add a collectionsAPI call ASSIGNPREFERREDLEADERS
> ------------------------------------------------
>
>                 Key: SOLR-6513
>                 URL: https://issues.apache.org/jira/browse/SOLR-6513
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Erick Erickson
>            Assignee: Erick Erickson
>
> Another sub-task for SOLR-6491. The ability to assign a preferred leader 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 these roles (or properties). This particular command would NOT re-elect leaders, just change the flag in the clusterstate.
> 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 preferred leaders for this collection would NOT be changed. Any node having 2 preferred leaders would have one added that would be taken from some node with > 3 preferred leaders.
> This probably needs an optional parameter, something like "includeInactiveNodes=true|false"



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

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