lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <markrmil...@gmail.com>
Subject Re: Removing last replica from a SolrCloud collection
Date Sun, 02 Feb 2014 05:01:34 GMT
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

http://about.me/markrmiller

On Fri, Jan 31, 2014 at 6:08 PM, David Smiley (@MITRE.org) <
DSMILEY@mitre.org> 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:
> http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Removing-last-replica-from-a-SolrCloud-collection-tp4114772.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>

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