lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <>
Subject Re: Removing last replica from a SolrCloud collection
Date Sun, 02 Feb 2014 05:50:48 GMT
We also really need to update the docs to use the collections API rather
than the pre configured core as well. I've been aiming to get the
preconfigured core (and hence collection) out of there by default for
solrcloud, but it's not easy, because I do think it still makes some sense
for non solrcloud mode and having another solr.xml to maintain and have the
user choose from kind of sucks.

One interesting idea is to simply leave it there and let the
zk=cluster_truth stuff take care of it. If you start in SolrCloud mode,
that core will belong to a collection that does not exist and be removed.

- Mark

On Sun, Feb 2, 2014 at 12:01 AM, Mark Miller <> wrote:

> It's expected behaviour. It's expected to change with the zk=cluster_truth
> mode that I hope we can start squeezing into 4.7.
> In the first couple releases of SolrCloud, there was no collections API. I
> did not have time to make it. Even what went in for the collections api was
> banged out in a very short amount of spare time I had and still needs lot's
> of additional work.
> Anyway, with no collections API, each replica being unloaded and
> unregistered was the only way to delete a collection. From what I've read,
> the hash ranges in zk work did not take this into account. I have not
> looked closely into it myself, so I don't know if that should be considered
> a bug or a rock and a hard place.
> We are left with a few of these kinds of warts due to time frames and
> working in harmony with a lot of existing Solr stuff.
> A large majority of those issues will be easily resolved with the
> zk=cluster_truth mode. The reason we didn't have that mode before is that
> it requires not only a collections api, but a nice, full, solid collections
> API. Most of that I've done in my spare time, though some of the later work
> was sponsored by Cloudera.
> We have come a long way with the collections api, and shalin and noble are
> helping work done this path, so it doesn't seem far off.
> Some of the zk=cluster_truth stuff might take a bit of time to get, but
> the initial mode (which should end up the default, and the old mode likely
> deprecated) should be fairly easy to get going.
> If the issue is really so nasty, perhaps we break back compat around this,
> given that the collections api can handle it properly now. My feeling has
> been more, let's just get an initial zk=cluster_truth done - there are lot
> of warts without it, and an initial zk=cluster_truth is not too much work,
> which is why I easily think it could be in 4.7.
> I guess it depends - if we don't think users will switch to the new mode
> and want to do things around unloading every replica in a collection while
> keeping the collection around, perhaps we should break back compat around
> this behaviour and force use of the collections API. I'd file a JIRA issue
> if you feel strongly about it. I have not really had to deal with any
> fallout from that yet.
> What do you mean you are hosed?
> All the SolrCores should be gone, so why does it matter so much that the
> collection is gone? In the days before the collections api, if you wanted
> to then create the collection again, just create a solrcore, same way a
> collection was created initially.
> Without the zk=cluster_truth mode, we have to support both collections api
> collections, and pre configured implicit collections, created and removed
> via SolrCores.
> --
> - Mark
> On Fri, Jan 31, 2014 at 6:08 PM, David Smiley ( <
>> wrote:
>> Hi,
>> If I issue either a core UNLOAD command, or a collection DELETEREPLICA
>> command,  (which both seem pretty much equivalent) it works but if there
>> are
>> no other replicas for the shard, then the metadata for the shard is
>> completely gone in clusterstate.json!  That's pretty disconcerting because
>> you're basically hosed.  Of course, why would I even want to do that?
>>  Well
>> I'm experimenting with ways to restore a backed-up replica to replace
>> existing data for the shard.
>> If this is unexpected behavior then I'll file a bug.
>> ~ David
>> -----
>>  Author:
>> --
>> View this message in context:
>> Sent from the Solr - User mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message