ILM phases+actions proceed sequentially. This implies if ILM gets stuck on a preceeding step it will never finish its sequence. A tabular format of the linked doc
actions\phase | hot | warm | cold | frozen | delete |
---|---|---|---|---|---|
set-priority | TRUE | TRUE | TRUE | f | f |
unfollow | TRUE | TRUE | TRUE | TRUE | f |
rollover | TRUE | f | f | f | f |
read-only | TRUE | TRUE | TRUE | f | f |
(searchable snapshot) | f | f | TRUE | f | f |
allocate | f | TRUE | TRUE | f | f |
migrate | f | TRUE | TRUE | f | f |
shrink | TRUE | TRUE | f | f | f |
force-merge | TRUE | TRUE | f | f | f |
freeze | f | f | TRUE | f | f |
searchable snapshots | TRUE | f | TRUE | TRUE | f |
wait for snapshot | f | f | f | f | TRUE |
delete | f | f | f | f | TRUE |
Kindly note
- Searchable Snapshot shows twice because it sequentially orders differently uniquely for cold (and I don't know how to sohw that better).
- A common misconception which this table highlights: indices enter their target
phase
before performing themigrate
action which means ILM is functioning as expected when shards are still on hot but index is incold/unfollow
. - There are some backpressure sub-action settings, e.g.
cold/searchable_snapshot
may flagforce_merge_index
which performs that as if it had been flagged underhot/force_merge
. This means the intended sequence would be on hot > force merge on hot > take searchable snapshot > allocate searchable snapshot onto cold. Note the index went into snapshot from hot and surfaced as searchable snapshot index on cold, but it did not go through thecold/migrate
process directly.
👻 THIS IS ADVANCED. This is purposely not documented in the official Elasticsearch Docs by the Dev team. Proceed at your own risk.
These generally the progressive steps/action that are taken, but they are not the guaranteed order. Steps may invoke any other step causing backtracking/jumping.