<p dir="auto">The idea is allow a simple, dynamically modifiable priority for indices. Something akin to:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="$ curl -XPUT host:9200/my-index/_settings -d '{
  &quot;index.priority&quot; : 1
}'"><pre class="notranslate"><code class="notranslate">$ curl -XPUT host:9200/my-index/_settings -d '{
  "index.priority" : 1
}'
</code></pre></div>
<p dir="auto">By default, all priorities would default with <code class="notranslate">index.priority : 0</code>, thus being of equal priority unless modified. From there, the comparison could go to index creation date/time as the next priority level, then finally by name for the final order.</p>
<blockquote>
<p dir="auto"><code class="notranslate">index.priority</code> &gt; <code class="notranslate">index.creation_date</code> &gt; reverse sorted index name</p>
</blockquote>
<p dir="auto">This allows pretty much every use case to specify recovery order for best-case recovery order for their use case. Time-based solutions would pretty much work out of the box because the creation date would prioritize recovery of <em>today's</em> index first, thus giving the best chance to return to fully replicated indexing as soon as possible. Similarly, falling back to the reverse sorted index name gives arbitrary--yet predictable--sorting for simultaneously-created indices (however unlikely) that have no time basis (<code class="notranslate">index-z</code>, <code class="notranslate">index-y</code>, ...), but YMD-formatted date/time strings will properly sort (<code class="notranslate">logstash-2015.05.03</code> will always come before <code class="notranslate">logstash-2015.05.02</code> or earlier dates). Finally, the arbitrary priority allows users to take control of the process for cases where there is no time basis, such as when a "main" index is created, but then minor indices are created from time-to-time. Even better, this would be as simple as setting it once with a high value, then not setting or selectively setting the minor indices.</p>
<p dir="auto">Feature request:</p>
<p dir="auto">When multiple shard replicas need recovery (eg, when you restart the whole cluster), it can be beneficial to get some indices green before others.<br>
In the Logstash case, getting the most recent indices by date.<br>
In other cases, there may be application demands on which index you really need back first.</p>
<p dir="auto">Being able to set a specific priority on indices, or have it automatically determined for date-based indices, would be quite helpful.</p>