[
https://issues.apache.org/jira/browse/SOLR-6517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154339#comment-14154339
]
Erick Erickson commented on SOLR-6517:
--------------------------------------
Hmmm, the discussion at SOLR-6095 will serve me in good stead, thanks.
Let's take this a bit at a time.
bq: I am confused by the 'sliceUnique' feature. What is the harm if I set two
preferredLeaders?
See the discussion at SOLR-6491 about why sysadmins need to impose some order.
This is not an absolute thing, IOW if the preferred leader isn't electable,
we'll fall back to the current election process. What we're talking about here
is shard leadership and relieving hotspots that are a consequence of the
current algorithm for electing shard leaders. Note that in tandem is SOLR-6513,
which automatically assigns exactly one sliceUnique role per slice across all
the physical nodes that host that collection. preferredLeader is a property
that a-priori has this restriction. Other properties can be sliceUnique as well
(or not, for properties other than preferredLeader this is up to the user).
bq: All that Solr needs to do is , just choose any one who is available. Users
would prefer this.
I can put you in touch with users of large, complex installations who will
explicitly disagree, see the discussion at SOLR-6491. Again, there's no
requirement at all that any installation have anything to do at all with the
preferred leader role, in which case Solr's behavior will be unchanged. The
user has to either 1> assign the preferredLeader property or 2> use the (new)
command to balance a property, one per shard, across all the nodes in a
collection (see SOLR-6513).
bq: They can set choose 2 nodes and even if one goes down the other can take up
the role. This is how overseer roles is set. I can set as many nodes as
overseers
I'm totally unclear here. There can be only one leader per slice. And there's
nothing about the special preferredLeader property that prevents this, if the
preferredLeader is unavailable the current election process is followed.
bq: The joinAtHead is a part of the overseer role feature.
Either I'm hallucinating or it's _also_ part of shard leadership election. I
confess I hadn't tracked down why I was hitting LeaderElector.joinElection
twice when bringing up a replica, now I know why. Once for adding an ephemeral
node for overseer election, and again for adding an ephemeral node for
shard-leader election. _Very_ good to know so I don't screw up the overseer
election! The discussion you pointed to looks like it's the model I'll look
into for this bit as well.
> 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
