# Wrong configuration can lead to unavailable shards **URL:** \ **Category:** Elasticsearch\ **Created:** [November 18, 2011, 9:37pm UTC](https://discuss.elastic.co/t/wrong-configuration-can-lead-to-unavailable-shards/5915 "2011-11-18T21:37:54Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Florent\_Becart](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/florent_becart/32/3074_2.png) [@Florent\_Becart](https://discuss.elastic.co/u/Florent_Becart)\ **Post date:** [November 18, 2011, 9:37pm UTC](https://discuss.elastic.co/t/wrong-configuration-can-lead-to-unavailable-shards/5915/1 "2011-11-18T21:37:54Z")
Hi everybody, I experienced an issue in my use of elasticsearch (0.18.2) on EC2 and I'd need some advices from the community in order to avoid it for the future. Here is the way I would create my index: curl -XPUT localhost:9200/my\_index -d ' index: analysis: analyzer: my\_analyzer: type: custom tokenizer: standard filter: [standard, lowercase, my\_synonym, my\_ngram] filter: my\_synonym: type: synonym _synonyms\_path: "analysis/my\_synonyms.txt"_ my\_ngram: type: nGram min\_gram: 3 max\_gram: 7 ' If the file my\_synonyms.txt is not available on the master node, the creation of the index fails (and this is fine to me). Here is the json response: {"error":"RemoteTransportException[indices/createIndex]]; nested: IndexCreationException[[my\_index] failed to create index]; nested: FailedToResolveConfigException[Failed to resolve config path [analysis/my\_synonyms.txt], tried file path [analysis/my\_synonyms.txt], path file [/data/elasticsearch/config/analysis/my\_synonyms.txt], and classpath]; ","status":500} But if it is on the master node but not on one of the nodes where a shard is assigned, here is the response: {"ok":true,"acknowledged":false} The thing is, in that case, some shards are still in the initializing state and do not work properly: "routing\_table" : { "indices" : { "en\_us" : { "shards" : { "0" : [ { "state" : "INITIALIZING", "primary" : true, "node" : "YN1TTiAHR9G\_n6MyR3\_wAg", "relocating\_node" : null, "shard" : 0, "index" : "en\_us" }, { "state" : "UNASSIGNED", "primary" : false, "node" : null, "relocating\_node" : null, "shard" : 0, "index" : "en\_us" } ], ... And obviously querying the cluster to index or search doesn't work as expected anymore. From what I understand, the shards creation is delegated to nodes of the cluster, and in case the shard can not initialize, the master node is not notified but instead it waits until the shard creation query times out. First, I realize that I made a big mistake by not having synchronized config folders for the different instances. I wonder if there is any good practice to avoid this situation. Here are my ideas: - not using any configuration file but only the REST/JSON APIs (but I can find any explanation about how to describe a multi-lines synonyms configuration via this API) - synchronizing/sharing the configuration folders between the different instances Also, I wish the cluster had a different behavior when this mistake occured. One thing that bothers me is that what happens varies depending on who the master of the cluster is - and this is subject to change at any time. And neither the JSON response nor the logs gave me useful information to understand what I was doing wrong. Thanks for your help Florent ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [November 20, 2011, 8:36am UTC](https://discuss.elastic.co/t/wrong-configuration-can-lead-to-unavailable-shards/5915/2 "2011-11-20T08:36:07Z")
Right, thats how it works. The index gets created on the master node as a "trial creation", and then shards get allocated and the index gets created again where shards end up being allocated. Synch'ing "config" location is one option, though its tricky, which one do you sync between the nodes... . An API to "upload" a file to the cluster and then reference it might make more sense, but its low priority. I think that the behavior is fine now, you can tell that the index has problems since when you try to operate against it, or try to see what the index status, you will see failures if it failed to be allocated on any node. On Fri, Nov 18, 2011 at 11:37 PM, Florent Bécart [florent.becart@gmail.com](mailto:florent.becart@gmail.com)wrote: > Hi everybody, > > I experienced an issue in my use of elasticsearch (0.18.2) on EC2 and I'd > need some advices from the community in order to avoid it for the future. > > Here is the way I would create my index: > curl -XPUT localhost:9200/my\_index -d ' > index: > analysis: > analyzer: > my\_analyzer: > type: custom > tokenizer: standard > filter: [standard, lowercase, my\_synonym, > my\_ngram] > filter: > my\_synonym: > type: synonym > \*synonyms\_path: "analysis/my\_synonyms.txt" > \* > my\_ngram: > type: nGram > min\_gram: 3 > max\_gram: 7 > ' > > If the file my\_synonyms.txt is not available on the master node, the > creation of the index fails (and this is fine to me). Here is the json > response: > {"error":"RemoteTransportException[indices/createIndex]]; nested: > IndexCreationException[[my\_index] failed to create index]; nested: > FailedToResolveConfigException[Failed to resolve config path > [analysis/my\_synonyms.txt], tried file path [analysis/my\_synonyms.txt], > path file [/data/elasticsearch/config/analysis/my\_synonyms.txt], and > classpath]; ","status":500} > > But if it is on the master node but not on one of the nodes where a shard > is assigned, here is the response: > {"ok":true,"acknowledged":false} > > The thing is, in that case, some shards are still in the initializing > state and do not work properly: > "routing\_table" : { > "indices" : { > "en\_us" : { > "shards" : { > "0" : [ { > "state" : "INITIALIZING", > "primary" : true, > "node" : "YN1TTiAHR9G\_n6MyR3\_wAg", > "relocating\_node" : null, > "shard" : 0, > "index" : "en\_us" > }, { > "state" : "UNASSIGNED", > "primary" : false, > "node" : null, > "relocating\_node" : null, > "shard" : 0, > "index" : "en\_us" > } ], > ... > > And obviously querying the cluster to index or search doesn't work as > expected anymore. From what I understand, the shards creation is delegated > to nodes of the cluster, and in case the shard can not initialize, the > master node is not notified but instead it waits until the shard creation > query times out. > > First, I realize that I made a big mistake by not having synchronized > config folders for the different instances. I wonder if there is any good > practice to avoid this situation. Here are my ideas: > > - not using any configuration file but only the REST/JSON APIs > (but I can find any explanation about how to describe a multi-lines > synonyms configuration via this API) > - synchronizing/sharing the configuration folders between the > different instances > > Also, I wish the cluster had a different behavior when this mistake > occured. One thing that bothers me is that what happens varies depending on > who the master of the cluster is - and this is subject to change at any > time. And neither the JSON response nor the logs gave me useful information > to understand what I was doing wrong. > > Thanks for your help > > Florent ---
**Author:** ![Florent\_Becart](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/florent_becart/32/3074_2.png) [@Florent\_Becart](https://discuss.elastic.co/u/Florent_Becart)\ **Post date:** [November 23, 2011, 2:31am UTC](https://discuss.elastic.co/t/wrong-configuration-can-lead-to-unavailable-shards/5915/3 "2011-11-23T02:31:39Z")
Thanks for the answer. I agree with everything you said. And I'm pleased to see the guide page for the "Synonym Token Filter" was updated and now contains everything I needed to know ([http://www.elasticsearch.org/guide/reference/index-modules/analysis/synonym-tokenfilter.html](http://www.elasticsearch.org/guide/reference/index-modules/analysis/synonym-tokenfilter.html)) Keep up the good work ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 3:47am UTC](https://discuss.elastic.co/t/wrong-configuration-can-lead-to-unavailable-shards/5915/4 "2017-07-06T03:47:44Z")