[
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: [email protected]
For additional commands, e-mail: [email protected]
