Hi Boaz, Thanks for your answer.
> In your case it means that if an ssd node got the search, it will run > on SSD otherwise it will on iodisk. I'm not sure this is what you > want. This is the effect I am looking for. During the period where I have a copy on ssds and on iodisks, I prefer to query the fastest ones. > ES tries the balance shards from the cluster perspective. It gives some > weight to spreading up the shards of an index but this just one > parameter.In your cases I suspect you have way more shards on the iodisk > nodes than on the ssds, which means that balancing will try to move shards > from iodisks to ssds if it can but not the other way around (as you expect). You're right, I'd like to have way more shards on iodisk indeed. Reading https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/cluster/routing/allocation/decider/AllocationDecidersModule.java#L66, I don't see any filter that will prevent allocation from ssd to iodisk. I understand that ES will see the situation as unbalanced and will try to rebalance it but I expect allocation filter to prevent those backward reallocation. > I would suggest you open an issue on github indicating that when shard > allocation awareness is causing unassigned shards if one of the > attribute values is blocked by an allocation filter Done: https://github.com/elasticsearch/elasticsearch/issues/8178 -- Grégoire -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/20141021132937.GB1762%40criteo-scalasto.criteo.prod. For more options, visit https://groups.google.com/d/optout.
