[jira] [Commented] (SOLR-5991) SolrCloud: Add API to move leader off a Solr instance

["Erick Erickson (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-5991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14551458#comment-14551458 ] 

Erick Erickson commented on SOLR-5991:
--------------------------------------

Right, the "superceded"JIRA (SOLR-6491) has the fixed revision in it (5.0).

Right, the REBALANCE stuff was all about a condition where leaders for a collection were all landing on the same node. There were many shards each with lots of replicas, so when starting the cluster fresh, the first node up would have a lot of leaders on it, and the additional load was noticeable. That code also doesn't really do much cross-collection, just within a collection.

The current Solr code pretty much assumes that all nodes hosting a collection are similar, I think the larger discussion is heterogeneous environments where you have a mix of hardware capabilities. You can do this a little now by assigning collections and/or replicas to specific nodes, but that's a manual process.

Assuming that there was a way to add node properties (your AVOID_RESPONSIBILITY flag), once that was set wouldn't DELETEREPLICA for all the replicas on that node essentially decommission it? I know we  discussed the idea of node (as opposed to either collection or replica) properties, but don't think that went anywhere as it wasn't needed at the time. And any such property would have to be be checked in the collection and replica creation code....

> SolrCloud: Add API to move leader off a Solr instance
> -----------------------------------------------------
>
>                 Key: SOLR-5991
>                 URL: https://issues.apache.org/jira/browse/SOLR-5991
>             Project: Solr
>          Issue Type: Bug
>          Components: SolrCloud
>    Affects Versions: 4.7.1
>            Reporter: Rich Mayfield
>            Assignee: Erick Erickson
>
> Common maintenance chores require restarting Solr instances.
> The process of a shutdown becomes a whole lot more reliable if we can proactively move any leadership roles off of the Solr instance we are going to shut down. The leadership election process then runs immediately.
> I am not sure what the semantics should be (either accomplishes the goal but one of these might be best):
> * A call to tell a core to give up leadership (thus the next replica is chosen)
> * A call to specify which core should become the leader



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org