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

Noble Paul edited comment on SOLR-6491 at 9/16/14 5:20 AM:
-----------------------------------------------------------

It was just an FYI . Just in case it helps you

BTW , to add to Shalin's point . I'm not yet convinced that the performance not 
is significant enough  . Do we have any real users reporting this as a problem?


was (Author: noble.paul):
It was just an FYI . Just in case it helps you

> Add preferredLeader as a ROLE and a collections API command to respect this 
> role
> --------------------------------------------------------------------------------
>
>                 Key: SOLR-6491
>                 URL: https://issues.apache.org/jira/browse/SOLR-6491
>             Project: Solr
>          Issue Type: Improvement
>    Affects Versions: 4.11, 5.0
>            Reporter: Erick Erickson
>            Assignee: Erick Erickson
>
> Leaders can currently get out of balance due to the sequence of how nodes are 
> brought up in a cluster. For very good reasons shard leadership cannot be 
> permanently assigned.
> However, it seems reasonable that a sys admin could optionally specify that a 
> particular node be the _preferred_ leader for a particular collection/shard. 
> During leader election, preference would be given to any node so marked when 
> electing any leader.
> So the proposal here is to add another role for preferredLeader to the 
> collections API, something like
> ADDROLE?role=preferredLeader&collection=collection_name&shard=shardId
> Second, it would be good to have a new collections API call like 
> ELECTPREFERREDLEADERS?collection=collection_name
> (I really hate that name so far, but you see the idea). That command would 
> (asynchronously?) make an attempt to transfer leadership for each shard in a 
> collection to the leader labeled as the preferred leader by the new ADDROLE 
> role.
> I'm going to start working on this, any suggestions welcome!
> This will subsume several other JIRAs, I'll link them momentarily.



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