[
https://issues.apache.org/jira/browse/SOLR-6517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14153718#comment-14153718
]
Erick Erickson commented on SOLR-6517:
--------------------------------------
[~markrmil...@gmail.com] [~noble.paul] [~shalinmangar] I know you guys have
been in this code a LOT, I'd appreciate any comments before I get too far into
mucking around in code that's
a> complex and
b> easy to mess up
I thought I'd ask if this has any possibility of working. I'll be pursuing this
no matter what, and if the conclusion is it's a horrible idea I'll chalk it up
to a "learning experience" ;).
All I'm looking for here is whether this seems like a reasonable approach, I'm
digging into details of how to make it happen.
Assuming SOLR-6512 (assign property to a replica, preferredLeader in this case)
and SOLR-6513 (distribute a unique property for one replica for each shard in a
collection evenly across all the nodes hosting any replicas for that
collection) are committed, I'm left with the leader-re-election problem. Each
slice will have one (and only one) replica with a property
"preferredLeader:true".
When a node joins the election process (LeaderElector.joinElection), it could
insert itself at the head of the list if preferredLeader==true. I'm looking at
the LeaderElector class. There's the very interesting method:
joinElection(ElectionContext context, boolean replacement,boolean joinAtHead).
I'm particularly interested in the "joinAtHead" parameter, seems like it's
exactly what I need. If this method were to look at the properties for the
replica and join at head if the preferredLeader property was set, it seems
ideal. It _also_ seems like the action of re-distributing the preferred leaders
command becomes triggering the leader election process for all the replicas in
the collection that are currently leaders but don't have the preferredLeader
property set (and some other replica for that slice _does_). Essentially this
is a "Hey you, stop being the leader now" call. The rest is automatic. I hope.
Of course I'll have to throttle the re-election process, don't want 50 leaders
being reelected at once. How is TBD.
I've done some preliminary testing and this seems to fit the bill for my needs,
I'll be working up a patch sometime Real Soon Now for your delectation unless
anyone sees gaping holes in the approach.
One thing I did note in joinElection (about line 252 on trunk). The string we
create the new leader sequence from is:
String firstInLine = nodes.get(1);
Seems like it should be
String firstInLine = nodes.get(0);
Problem is, say I have the sequence numbers
node1-0
node2-1
and I do the joinElection bit with joinAtHead=true (which I don't think we ever
do actually). Then I wind up with
node1-0
node2-1
node3-1
I'll change it unless there's a good reason not to.
> 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
