[ 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