[
https://issues.apache.org/jira/browse/SOLR-6491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14136826#comment-14136826
]
Ramkumar Aiyengar commented on SOLR-6491:
-----------------------------------------
The problem with the switch leader operation is that the external mechanism now
has no idea surrounding when to actually run the command. If you were unlucky
enough, you could run a switch leader, a minute later a ZK blip happens causing
an election, and your command has effectively lost value.
I get your concern with the topology changing causing the manual overrides to
not make sense, but that's true of any manual override setting. To draw a
parallel, lets say we set an overseer role on a machine and then end up adding
a lot of collections to the same machine -- now the machine is taxed already
due to too many collections and that node being the choice for the overseer is
a bad one.
My point is that all these manual expert operations are only invalidated by
other external operations which aren't implicitly initiated by SolrCloud. So
it's the prerogative of the expert to ensure that the external operations they
do are in sync with any expert override commands they issue.
> Umbrella JIRA for managing the leader assignments
> -------------------------------------------------
>
> 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]
