[
https://issues.apache.org/jira/browse/SOLR-6517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14188733#comment-14188733
]
Erick Erickson commented on SOLR-6517:
--------------------------------------
First, there aren't any guarantees here, it tries its best. For instance, the
node may be down etc...
Barring that though, it's pretty straightforward. The meat of the processing is
in
collecitonsHandler.handleBalanceLeaders.
get the DocCollection from the cluster state.
for each slice {
for each replica {
if (the replica is active and NOT the leader and has the preferredLeader
property set) queue it up to become the leader
}
}
There's some bookkeeping here to respect the various parameters about how many
to reassign at once and how long to wait (maxAtOnce and maxWaitSeconds) as well
as construct a pretty response giving all the info it can. This latter is one
benefit of the heavy lifting being in collectionsHandler rather than over in
the Overseer.
> CollectionsAPI call REBALANCELEADERS
> ------------------------------------
>
> Key: SOLR-6517
> URL: https://issues.apache.org/jira/browse/SOLR-6517
> Project: Solr
> Issue Type: New Feature
> Affects Versions: 5.0, Trunk
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6517.patch, SOLR-6517.patch, SOLR-6517.patch
>
>
> Perhaps the final piece of SOLR-6491. Once the preferred leadership roles are
> assigned, there has to be a command "make it so Mr. Solr". This is something
> of a placeholder to collect ideas. One wouldn't want to flood the system with
> hundreds of re-assignments at once. Should this be synchronous or asnych?
> Should it make the best attempt but not worry about perfection? Should it???
> a collection=name parameter would be required and it would re-elect all the
> leaders that were on the 'wrong' node
> I'm thinking an optionally allowing one to specify a shard in the case where
> you wanted to make a very specific change. Note that there's no need to
> specify a particular replica, since there should be only a single
> preferredLeader per slice.
> This command would do nothing to any slice that did not have a replica with a
> preferredLeader role. Likewise it would do nothing if the slice in question
> already had the leader role assigned to the node with the preferredLeader
> role.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
