[
https://issues.apache.org/jira/browse/SOLR-6513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14139906#comment-14139906
]
Erick Erickson commented on SOLR-6513:
--------------------------------------
I'm thinking that this should have at least one optional parameter, something
like "onlyLiveNodes" which would default to "true". The idea here would be that
you might want to assign preferred leader roles to all the nodes in your
cluster, even if some of them were offline (temporarily one assumes).
And what about a nodeset parameter? The idea here would be to evenly balance
the preferred leaders amongst a specific set of nodes for all the shards in a
collection. That would be an easy thing to implement, it just makes gathering
the list of potential nodes with the role assigned manual. But frankly that
doesn't seem like a great idea, one of those things that just because it's easy
doesn't mean it's worthwhile. I'd need a good argument for supporting it at
this point, thus I'm mentioning it.
> 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]
