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

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

bq: So what is the command REBALANCELEADERS doing ?
Perhaps nothing if all the nodes with preferredLeader=true are already leaders. 
But just because a node inserts itself at the head of the queue does _not_ mean 
its the leader, that operation puts it just after the current leader, i.e. 
"next in line". It'll only become the leader at if the current leader goes down 
for some reason. So REBALANCELEADERS will cause any shard  where the current 
leader is not the preferredLeader to re-elect leadership.

bq: Why can't I specify a 'slice' only to rebalance?
No technical reason at all. I didn't need that capability, my specific task was 
on a collection-wide basis. There's no reason that couldn't be an optional 
parameter though, it'd be simple to do so feel free if there's a real-world 
use-case you need to support. But for the situation I'm looking at, there may 
be 10s to 100s of slices, so it'd be tedious to do them one at a time, not to 
mention error-prone.


> 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]

Reply via email to