[
https://issues.apache.org/jira/browse/SOLR-6517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155266#comment-14155266
]
Erick Erickson commented on SOLR-6517:
--------------------------------------
bq: I am asking why don't we push the option to a request param and the users
get the power of choosing multilple preferred leaders and if one shard goes
down the other can clearly take up the that role
Because I feel it's an unnecessary complexity that doesn't add enough value to
justify doing it now. Leadership election will still occur if the preferred
leader is down, just as it does not. Additionally auto-assigning the property
becomes harder if multiples are allowed.
> CollectionsAPI call ELECTPREFERREDLEADERS
> -----------------------------------------
>
> 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
>
> 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
