[
https://issues.apache.org/jira/browse/SOLR-6513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-6513:
---------------------------------
Attachment: SOLR-6513.patch
Not ready to commit yet, certainly have to beef up the tests. Putting it up so
people can see what this is starting to look like and comment. I've done some
_very_ preliminary testing and the roles seem to be assigned as I expect,
significantly more testing to do as well as looking over the code in more
detail with fresh eyes.
Certainly a question whether the new private class in Overseer.java belongs
there or should be a separate file, it has no applicability outside Overseer
that I'm predicting so it doesn't seem misplaced. But the Overseer.java file is
now approaching 1,900 lines.
> 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
> Attachments: SOLR-6513.patch
>
>
> 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]
