[ 
https://issues.apache.org/jira/browse/SOLR-3512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Laird updated SOLR-3512:
-----------------------------

    Issue Type: New Feature  (was: Improvement)
    
> Create API for managing nodes within SolrCloud
> ----------------------------------------------
>
>                 Key: SOLR-3512
>                 URL: https://issues.apache.org/jira/browse/SOLR-3512
>             Project: Solr
>          Issue Type: New Feature
>          Components: SolrCloud
>    Affects Versions: 4.0
>            Reporter: Andy Laird
>
> Currently there does not seem to be any "clean" way to remove a particular 
> Solr node from a ZooKeeper collection running in SolrCloud.  I watched the 
> talk at Lucene Revolution 2012 about this area and it seems like the 
> recommended approach at present is to just shut down the node.  This is 
> problematic for a couple reasons:  one is that it creates a reliance on the 
> ZK config (how soon will ZK know that the node is gone?) and creates a 
> potentially bad user experience (how many queries will get sent to the node 
> that was just shut down before the next tick elapses?).  It also makes it 
> impossible to use the node in an "offline" state -- for example, if something 
> went wrong on the box it might be good to look at a dump of the running 
> process, etc. but if it's turned off we can't easily do that.  
> Ideally there could be a series of core commands/primitives that one could 
> issue to any Solr node to do things like remove a node from a ZK collection, 
> re-connect to a ZK instance, a particular collection, etc.  It might also be 
> useful to be able to start up a Solr node without initially connecting to ZK.
> I looked at [SOLR-3488|http://issues.apache.org/jira/browse/SOLR-3488] but 
> that issue seems more related to managing collections within ZK, not so much 
> about nodes within a particular collection.  Apologies if these topics are 
> covered there.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to