[
https://issues.apache.org/jira/browse/SOLR-6491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14136680#comment-14136680
]
Steven Bower commented on SOLR-6491:
------------------------------------
I think the preferredLeader flag is a good approach.. It gives explicit control
to people who require it.. When building extremely high performance/large scale
systems being able to know exactly where things are occurring is important... I
don't see this as in conflict with a more automated approach in fact I think
they could play nicely together (ie use explicit choice first and if that node
isn't available fall back to balanced distribution algo.
Also the cause of this ganging up of the leaders on a single node is due to
rolling restarts of a solr instances/servers for maintenance/upgrades/etc...
Because election algo in ZK creates an array of numbered ephemeral nodes and
choses the lowest, when you sequentially bounce instances in the same order you
eventually sort the servers in the array used in the leader election for all
shards... when you have lots of shards you end up with all the leaders on a
single (or very few servers)... This effect occurs regardless of whether
multiple shards are in a single instance, in multiple instances on a server or
multi-tenant configs with multiple unrelated solr clusters running on the same
server (when you bounce all instances on a server)...
> 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]
