lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jamie Johnson (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-2765) Shard/Node states
Date Sat, 08 Oct 2011 00:35:29 GMT

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

Jamie Johnson commented on SOLR-2765:
-------------------------------------

That answers part of it, I am trying to consider this with regards to the project I am currently
working.  On this project we have the case where we are also interested in additional slices/shards
becoming available serving more data.  So in this case it's not a question of replicas but
completely new slices.  

We also distribute our queries (much like the latest solrj on trunk does) where we randomly
choose a server with the role "searcher", I think this means that each searcher needs to be
aware of all of the other available servers with the role "searcher" to be able to execute
the query. I suppose the servers with role "indexer" do not need to build the watchers as
they are not being used in the query process (assuming they aren't also searchers).  

I am just not sure that we can guarantee that the servers won't need to be aware of all other
servers.  Someone more familiar with the workings of how queries are distributed may have
a better idea in this regard.

All of that being said it may be simpler (as mentioned previously) to create the watchers
on the live nodes and move the information that is in the collection structure there.  We
could then create a watcher on the directory (node is available or removed) and the ephemeral
nodes (shard configuration changed) and go on with life.  This still gives us an n^2 type
of setup though, but in this regard I defer to Mark as he is much more familiar with the inner
workings of solr and solr cloud than I.  This may also be something that we'd want to reach
out to our Zookeeper brethren to get their input on how something like this could be managed
and if this is destined to fail as n increases.
                
> Shard/Node states
> -----------------
>
>                 Key: SOLR-2765
>                 URL: https://issues.apache.org/jira/browse/SOLR-2765
>             Project: Solr
>          Issue Type: Sub-task
>          Components: SolrCloud, update
>            Reporter: Yonik Seeley
>             Fix For: 4.0
>
>         Attachments: incremental_update.patch, shard-roles.patch
>
>
> Need state for shards that indicate they are recovering, active/enabled, or disabled.

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


Mime
View raw message