[
https://issues.apache.org/jira/browse/SOLR-5209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867720#comment-13867720
]
Christine Poerschke commented on SOLR-5209:
-------------------------------------------
Hello. Just wanted to follow-up if we could proceed with this patch? To either
reduce or completely remove the cascading behaviour UNLOAD currently has,
between them DELETESHARD and DELETECOLLECTION should allow for shard and
collection removal if that was to be required after UNLOAD-ing.
+original clusterstate+
{noformat}
"collection1" : {
shards : {
"shard1":{ "range":"...", "state" : "active", "replicas":{ {
"core":"collection1_shard1" } } },
"shard2":{ "range":"...", "state" : "active", "replicas":{ {
"core":"collection1_shard2" } } }
}, ...
},
"collection2" : {
...
}
{noformat}
+current clusterstate after UNLOAD of collection1 shard1+
(The UNLOAD of the last shard1 replica cascade-triggered the removal shard1
itself.)
{noformat}
"collection1" : {
shards : {
"shard2":{ "range":"...", "state" : "active", "replicas":{ {
"core":"collection1_shard2" } } }
}, ...
},
"collection2" : {
...
}
{noformat}
+expected clusterstate after UNLOAD of collection1 shard1+
(There are now no replica in shard1. If one wanted to get rid of the shard then
DELETESHARD could be modified to allow removal of active shards without
replicas (currently DELETESHARD only removes shards that are state=inactive or
state=recovery or range=null).)
{noformat}
"collection1" : {
shards : {
"shard1":{ "range":"...", "state" : "active", "replicas":{} },
"shard2":{ "range":"...", "state" : "active", "replicas":{ {
"core":"collection1_shard2" } } }
}, ...
},
"collection2" : {
...
}
{noformat}
+current clusterstate after UNLOAD of collection1 shard1 and UNLOAD of
collection1 shard2+
(The UNLOAD of the last shard2 replica cascade-triggered the removal shard2
itself, and then the removal of the last shard cascade-triggered the removal of
collection1 itself.)
{noformat}
"collection2" : {
...
}
{noformat}
+expected clusterstate after UNLOAD of collection1 shard1 and UNLOAD of
collection1 shard2+
(There are now no replica in shard1 and shard2. If one wanted to get rid of
shard1 and shard2 then DELETESHARD could be modified and used as per above. If
one wanted to get rid of collection1 itself then DELETECOLLECTION could be
used.)
{noformat}
"collection1" : {
shards : {
"shard1":{ "range":"...", "state" : "active", "replicas":{} },
"shard2":{ "range":"...", "state" : "active", "replicas":{} }
}, ...
},
"collection2" : {
...
}
{noformat}
> cores/action=UNLOAD of last replica removes shard from clusterstate
> -------------------------------------------------------------------
>
> Key: SOLR-5209
> URL: https://issues.apache.org/jira/browse/SOLR-5209
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Affects Versions: 4.4
> Reporter: Christine Poerschke
> Assignee: Mark Miller
> Attachments: SOLR-5209.patch
>
>
> The problem we saw was that unloading of an only replica of a shard deleted
> that shard's info from the clusterstate. Once it was gone then there was no
> easy way to re-create the shard (other than dropping and re-creating the
> whole collection's state).
> This seems like a bug?
> Overseer.java around line 600 has a comment and commented out code:
> // TODO TODO TODO!!! if there are no replicas left for the slice, and the
> slice has no hash range, remove it
> // if (newReplicas.size() == 0 && slice.getRange() == null) {
> // if there are no replicas left for the slice remove it
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
