[
https://issues.apache.org/jira/browse/SOLR-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788849#action_12788849
]
Mark Miller commented on SOLR-1277:
-----------------------------------
Missed the latest comment - I'm going to commit this base to branch. I've been
playing around with further details, but I really think we need to start
nailing things down a little more - not so that we can't pull the nails up, but
so that we can start pushing forward.
Has anyone looked at Yonik's SolrCloud wiki page? I know some have - any
comments?
I'd like to be more clear on the layout.
And how the model/state distinction is going to work. Two paths that are
essentially the same? model/state, both with the same layout? Then you setup
what you'd like with the model, but the state reports whats actually going on?
eg the model will list all of the hosts, but the state may show that only n of
them are available? I know thats the idea, but whats the impl?
How about how a host registers itself? It would be nice to do this
automatically, but as Yonik mentions in the wiki, a host can have multiple
names. Do we just require that a user uses the name that we choose? Do we make
it so that any name the users tries works? (by enumerating every hostname). Do
we allow the user to manually override what to use as that host address?
So then the idea would: a user sets up everything in the model (we need good
tools for this if thats the case), then the system builds the state
automatically? When a search request comes in, we grab which shards to hit,
cache them, and use them until a Watch event tells us to look again? I know
thats starting to get a little low level, but just trying to spark some forward
momentum discussion.
Any opinions on going shards to nodes or nodes to shards in the layout?
> Implement a Solr specific naming service (using Zookeeper)
> ----------------------------------------------------------
>
> Key: SOLR-1277
> URL: https://issues.apache.org/jira/browse/SOLR-1277
> Project: Solr
> Issue Type: New Feature
> Affects Versions: 1.4
> Reporter: Jason Rutherglen
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: log4j-1.2.15.jar, SOLR-1277.patch, SOLR-1277.patch,
> SOLR-1277.patch, SOLR-1277.patch, zookeeper-3.2.1.jar
>
> Original Estimate: 672h
> Remaining Estimate: 672h
>
> The goal is to give Solr server clusters self-healing attributes
> where if a server fails, indexing and searching don't stop and
> all of the partitions remain searchable. For configuration, the
> ability to centrally deploy a new configuration without servers
> going offline.
> We can start with basic failover and start from there?
> Features:
> * Automatic failover (i.e. when a server fails, clients stop
> trying to index to or search it)
> * Centralized configuration management (i.e. new solrconfig.xml
> or schema.xml propagates to a live Solr cluster)
> * Optionally allow shards of a partition to be moved to another
> server (i.e. if a server gets hot, move the hot segments out to
> cooler servers). Ideally we'd have a way to detect hot segments
> and move them seamlessly. With NRT this becomes somewhat more
> difficult but not impossible?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
