lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-6513) Add a collectionsAPI call ASSIGNPREFERREDLEADERS
Date Sat, 13 Sep 2014 22:49:33 GMT

    [ 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


Mime
View raw message