[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
