lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <>
Subject Re: LotsOfCores feature
Date Fri, 07 Jun 2013 04:15:13 GMT
On 6/6/2013 6:32 PM, Jack Krupansky wrote:

<big snip>

> This would be a lot more of a true "Solr Cloud" than the "cluster"
> support that we have today.
> And the "CloudKeeper" itself might be a "traditional" SolrCloud cluster,
> except that it needs to be multi-data center.

I like a lot of what you said in the huge section that I didn't quote.
It inspired a few ideas.

Recently I was thinking about how we might change the names of certain
things in Solr to get rid of historical throwbacks, given that we are
redefining solr.xml and other config files in the dev branches.  Your
ideas are similar to something I thought about where you'd have an
abstraction higher than a collection, something for which I couldn't
think of a name.

Another idea: One characteristic of SolrCloud is that the master/slave
model goes away.  In some ways, this is a very good thing, but it does
get rid of the ability to index on one set of machines and query on another.

What if we combined master/slave replication with SolrCloud?  What I'm
envisioning here is a master cloud with a low replication factor like 2
or 3, and a slave cloud with a potentially high replication actor.  They
would actually be part of the same cloud, sharing a zookeeper ensemble.
 It would need to support the ability to split configurations, either
with two config sets for one cloud or the ability to include master and
slave configs, similar to how we split index and query analyzers in the

Related side issue: The fact that SolrCloud uses the standard
replication handler has led to lots of confusion.  People look at the
replication section for their cores and are very confused by what they
see there, and when we tell them that SolrCloud's replicas don't
normally use replication, they get REALLY confused.  How about we set
aside a dedicated handler name (/cloudreplication, perhaps) for an
internally defined replication handler specific for SolrCloud recovery?


View raw message