[ 
https://issues.apache.org/jira/browse/SOLR-6517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14193930#comment-14193930
 ] 

Erick Erickson commented on SOLR-6517:
--------------------------------------

Yep. I'm not sure what you're concerned about. Do you see a problem?

REBALANCELEADERS   does, indeed, do just that, there's no real magic here.

Look at the code in ZkController.register if you're wondering how 
preferredLeaders join at the head of the queue.

> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to