[
https://issues.apache.org/jira/browse/SOLR-6491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14138928#comment-14138928
]
Erick Erickson commented on SOLR-6491:
--------------------------------------
bq: The good thing about this command is I can just do it after a beer without
screwing up the cluster badly
Ahhh, yes. The "drunken monkey proof" API. I worked with a guy once who had a
theory that if you couldn't understand your code after 3 beers it was too
complicated and you should simplify it, although on the next day. Ever since
I've tried to get places I work to institute the Friday Afternoon Beer Code
Review but failed. I _really_ bet that would be a way to get more code reviews!
What we're talking about here should do that however. There's the auto assign
ticket to distribute the preferred roles evenly and the "make it so" ticket to
actually change leadership. SOLR-6513 and SOLR-6517.
We could also extend the leader election process to automatically do this,
there's nothing precluding that here.
So it's feeling like we can carry this idea forward, probably later today I'll
post the assign-replica-property code for review and start working on 6513 and
we'll go from there?
> 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: 5.0, 6.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]
