2020-04-28 19:38:01 -04:00
|
|
|
[role="xpack"]
|
|
|
|
[testenv="basic"]
|
|
|
|
[[ilm-index-lifecycle]]
|
|
|
|
=== Index lifecycle
|
|
|
|
++++
|
|
|
|
<titleabbrev>Index lifecycle</titleabbrev>
|
|
|
|
++++
|
|
|
|
|
2020-08-12 11:36:27 -04:00
|
|
|
{ilm-init} defines five index lifecycle _phases_:
|
2020-04-28 19:38:01 -04:00
|
|
|
|
2020-06-05 21:55:51 -04:00
|
|
|
* **Hot**: The index is actively being updated and queried.
|
|
|
|
* **Warm**: The index is no longer being updated but is still being queried.
|
|
|
|
* **Cold**: The index is no longer being updated and is seldom queried. The
|
2020-04-28 19:38:01 -04:00
|
|
|
information still needs to be searchable, but it's okay if those queries are
|
|
|
|
slower.
|
2020-08-12 11:36:27 -04:00
|
|
|
* **Frozen**: The index is no longer being updated and is seldom queried. The
|
|
|
|
queries are performing longer-term analyses for which a slower response is
|
|
|
|
acceptable.
|
2020-06-05 21:55:51 -04:00
|
|
|
* **Delete**: The index is no longer needed and can safely be removed.
|
2020-04-28 19:38:01 -04:00
|
|
|
|
|
|
|
An index's _lifecycle policy_ specifies which phases
|
|
|
|
are applicable, what actions are performed in each phase,
|
|
|
|
and when it transitions between phases.
|
|
|
|
|
|
|
|
You can manually apply a lifecycle policy when you create an index.
|
|
|
|
For time series indices, you need to associate the lifecycle policy with
|
|
|
|
the index template used to create new indices in the series.
|
|
|
|
When an index rolls over, a manually-applied policy isn't automatically applied to the new index.
|
|
|
|
|
|
|
|
[discrete]
|
|
|
|
[[ilm-phase-transitions]]
|
|
|
|
=== Phase transitions
|
|
|
|
|
|
|
|
{ilm-init} moves indices through the lifecycle according to their age.
|
|
|
|
To control the timing of these transitions, you set a _minimum age_ for each phase.
|
|
|
|
For an index to move to the next phase, all actions in the current phase must be complete and
|
|
|
|
the index must be older than the minimum age of the next phase.
|
|
|
|
|
|
|
|
The minimum age defaults to zero, which causes {ilm-init} to move indices to the next phase
|
|
|
|
as soon as all actions in the current phase complete.
|
|
|
|
|
2020-05-13 19:12:37 -04:00
|
|
|
If an index has unallocated shards and the <<cluster-health,cluster health status>> is yellow,
|
|
|
|
the index can still transition to the next phase according to its {ilm} policy.
|
|
|
|
However, because {es} can only perform certain clean up tasks on a green
|
|
|
|
cluster, there might be unexpected side effects.
|
|
|
|
|
|
|
|
To avoid increased disk usage and reliability issues,
|
|
|
|
address any cluster health problems in a timely fashion.
|
|
|
|
|
|
|
|
|
2020-04-28 19:38:01 -04:00
|
|
|
[discrete]
|
|
|
|
[[ilm-phase-execution]]
|
|
|
|
=== Phase execution
|
|
|
|
|
|
|
|
{ilm-init} controls the order in which the actions in a phase are executed and
|
|
|
|
what _steps_ are executed to perform the necessary index operations for each action.
|
|
|
|
|
|
|
|
When an index enters a phase, {ilm-init} caches the phase definition in the index metadata.
|
|
|
|
This ensures that policy updates don't put the index into a state where it can never exit the phase.
|
|
|
|
If changes can be safely applied, {ilm-init} updates the cached phase definition.
|
|
|
|
If they cannot, phase execution continues using the cached definition.
|
|
|
|
|
2020-05-11 18:10:57 -04:00
|
|
|
{ilm-init} runs periodically, checks to see if an index meets policy criteria,
|
|
|
|
and executes whatever steps are needed.
|
|
|
|
To avoid race conditions, {ilm-init} might need to run more than once to execute all of the steps
|
|
|
|
required to complete an action.
|
|
|
|
For example, if {ilm-init} determines that an index has met the rollover criteria,
|
|
|
|
it begins executing the steps required to complete the rollover action.
|
|
|
|
If it reaches a point where it is not safe to advance to the next step, execution stops.
|
|
|
|
The next time {ilm-init} runs, {ilm-init} picks up execution where it left off.
|
|
|
|
This means that even if `indices.lifecycle.poll_interval` is set to 10 minutes and an index meets
|
|
|
|
the rollover criteria, it could be 20 minutes before the rollover is complete.
|
|
|
|
|
2020-04-28 19:38:01 -04:00
|
|
|
[discrete]
|
|
|
|
[[ilm-phase-actions]]
|
|
|
|
=== Phase actions
|
|
|
|
|
|
|
|
{ilm-init} supports the following actions in each phase.
|
|
|
|
|
|
|
|
* Hot
|
|
|
|
- <<ilm-set-priority,Set Priority>>
|
|
|
|
- <<ilm-unfollow,Unfollow>>
|
2020-08-31 11:02:41 -04:00
|
|
|
- <<ilm-forcemerge,Force Merge>>
|
2020-04-28 19:38:01 -04:00
|
|
|
- <<ilm-rollover,Rollover>>
|
|
|
|
* Warm
|
|
|
|
- <<ilm-set-priority,Set Priority>>
|
|
|
|
- <<ilm-unfollow,Unfollow>>
|
|
|
|
- <<ilm-readonly,Read-Only>>
|
|
|
|
- <<ilm-allocate,Allocate>>
|
|
|
|
- <<ilm-shrink,Shrink>>
|
|
|
|
- <<ilm-forcemerge,Force Merge>>
|
|
|
|
* Cold
|
|
|
|
- <<ilm-set-priority-action,Set Priority>>
|
|
|
|
- <<ilm-unfollow-action,Unfollow>>
|
|
|
|
- <<ilm-allocate,Allocate>>
|
|
|
|
- <<ilm-freeze,Freeze>>
|
2020-06-30 09:22:32 -04:00
|
|
|
ifdef::permanently-unreleased-branch[]
|
2020-04-28 19:38:01 -04:00
|
|
|
- <<ilm-searchable-snapshot, Searchable Snapshot>>
|
2020-06-30 09:22:32 -04:00
|
|
|
endif::[]
|
2020-08-12 11:36:27 -04:00
|
|
|
* Frozen
|
|
|
|
- <<ilm-set-priority-action,Set Priority>>
|
|
|
|
- <<ilm-unfollow-action,Unfollow>>
|
|
|
|
- <<ilm-allocate,Allocate>>
|
|
|
|
- <<ilm-freeze,Freeze>>
|
|
|
|
ifdef::permanently-unreleased-branch[]
|
|
|
|
- <<ilm-searchable-snapshot, Searchable Snapshot>>
|
|
|
|
endif::[]
|
2020-04-28 19:38:01 -04:00
|
|
|
* Delete
|
|
|
|
- <<ilm-wait-for-snapshot-action,Wait For Snapshot>>
|
|
|
|
- <<ilm-delete,Delete>>
|
|
|
|
|