Moving the shard was a good idea but unfortunately:
"error": "ElasticsearchIllegalArgumentException[[move_allocation] can't
move [ds_infrastructure-storage-na-qtree], shard is not started (state =
Allocate didn't work either as the shard was not unallocated.
On Wednesday, 11 June 2014 09:03:44 UTC+2, Boaz Leskes wrote:
The fix option of check_on_startup checks indices and removes the
segments that are corrupted, this is a lucene level operation and is
primarily meant to be used in extreme cases where you only had one copy of
shards and those got corrupted.
In your cases, since the primaries are good, the easiest would be to use
the reroute API to tell elasticsearch to move the replicas that have been
corrupted to another node. When moving replicas, ES actually makes a new
copy of the primary as it protects against exactly these kinds of
On Tuesday, June 10, 2014 9:23:56 AM UTC+2, Michael Salmon wrote:
I had a problem with corrupted shards so I restarted my cluster with
"index.shard.check_on_startup: fix" and the corrupted shards were fixed
(i.e. deleted). Unfortunately the replicas and primaries then had differing
numbers of documents despite them all being green. Fortunately the
primaries always had more than the replicas so that I hopefully haven't
To fix this I set the number of replicas to 0 then 1 on all the indices
that had mismatches. Is there a better technique? I really didn't like
having just one copy of my data even if it was for a short time.
I am still running 1.1.1, is this addressed by a later release?
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/7ae6a3cf-d51b-4d04-bbae-e7f085be9a90%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.