[
https://issues.apache.org/jira/browse/SOLR-6491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14127074#comment-14127074
]
Erick Erickson commented on SOLR-6491:
--------------------------------------
Right, Noble's comment on the dev list that it would be nice to explain _why_
this is desirable is well taken. Heck, _I_ know what I'm thinking, don't
others? ;)....
See the referenced JIRAs. But what I've seen "in the wild" is that depending on
how a cluster comes up, all the leaders can wind up on a single (or small
number) of machines. Since updates do put some extra load on the leader, this
can create an odd load distribution.
There's no really good external method to rebalance leaders without bouncing
nodes and hoping that leaders come up "in the right place". The idea here is to
allow the sys admin to establish a "model leader distribution" via the
"preferredLeader" attribute, and then be able to trigger something like
"rebalance leaders for collection X" to bring the actuality close to the model.
The preferredLeader role would also tend to bring the actual leader nodes for
particular collections into congruence with the model over time I'd guess, b/c
any time leader election takes place for a shard, the preferred leader would
probably be elected as leader (if it's up).
Nothing about this is set in stone. By that I mean the preferredLeader role is
a "hint", not an absolute requirement. Really a "try me first" operation not
"require that I be the leader" rule.
I'm a bit nervous about the "rebalance leaders for collection X" command, I'm
not quite sure yet how/whether one needs to throttle this. I mean if a cluster
has 150 shards, having them all re-elect leaders at the same time while under
heavy indexing load seems ....fraught. I don' think this is insurmountable
however, I'll see some more about this as I get deeper into the code.
> 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: 5.0, 4.11
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
