[
https://issues.apache.org/jira/browse/SOLR-6517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154963#comment-14154963
]
Erick Erickson edited comment on SOLR-6517 at 10/1/14 3:47 PM:
---------------------------------------------------------------
bq: A user wants to move the shard leader to a particular replica and he
invokes a action=SETREPLICAPROP&prop=prefrerredLeader&val=true . Here I should
be able to pass a param "sliceUnique=true" which will remove the property from
other replicas if the param is not passed two replicas will have the same value
This is exactly what happens with one twist. "preferredLeader" is a known
property that automatically enforces the sliceUnique=true parameter. All other
properties' uniqueness are completely under the control of the user.
sliceUnique defaults to 'false'.
I don't see the practical use of having multiple preferred leaders per slice. I
can imagine having a weight attached to the property governing where it
inserted itself in the ephemeral node list, but that's a complexity I'll save
for another JIRA I think ;).
edit - Or perhaps we'll add the ability to define multiple preferred leader
properties per slice at some point in the future. How that interacts with
SOLR-6513 where the property is auto-balanced amongst all nodes is an open
question that I don't want to address right now. "progress, not perfection" and
all that.
was (Author: erickerickson):
bq: A user wants to move the shard leader to a particular replica and he
invokes a action=SETREPLICAPROP&prop=prefrerredLeader&val=true . Here I should
be able to pass a param "sliceUnique=true" which will remove the property from
other replicas if the param is not passed two replicas will have the same value
This is exactly what happens with one twist. "preferredLeader" is a known
property that automatically enforces the sliceUnique=true parameter. All other
properties' uniqueness are completely under the control of the user.
sliceUnique defaults to 'false'.
I don't see the practical use of having multiple preferred leaders per slice. I
can imagine having a weight attached to the property governing where it
inserted itself in the ephemeral node list, but that's a complexity I'll save
for another JIRA I think ;).
> 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: [email protected]
For additional commands, e-mail: [email protected]
