概述
本文是在本人學習研究ElasticSearch的生命週期管理策略時，發現官方未提供中文文件，有的也是零零散散，此文主要是翻譯官方文件Policy phases and actions模組。
注：基於6.7版本
索引生命週期中有四個階段，按執行順序排列。
| 名稱 | 描述 |
|---|---|
hot |
該索引正在積極寫入 |
warm |
索引通常不會被寫入，但仍然會被查詢 |
cold |
索引不再更新，很少查詢。資訊仍然需要搜尋，但如果這些查詢速度較慢也沒關係。 |
delete |
不再需要索引，可以安全刪除 |
這些階段中的每一個都稱為階段。策略不需要為索引配置每個階段。例如，一個策略可以僅定義熱階段和刪除階段，而另一個策略可以定義所有四個階段。
時間（Timing）
索引進入某階段是基於該階段設定的min_age引數。當索引的“年齡”大於該階段設定的的min_age之前，索引才會進入階段min_age。使用持續時間格式配置引數（請參閱時間單位）。
min_age如果未指定，則每個階段的預設值為零秒0s。
示例
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"warm": {
"min_age": "1d",
"actions": {
"allocate": {
"number_of_replicas": 1
}
}
},
"delete": {
"min_age": "30d",
"actions": {
"delete": {}
}
}
}
}
}
以上示例策略，在一天之後將索引移動到暖階段。在此之前，該索引處於等待狀態。進入暖階段後，它將等待30天后才能進入刪除階段並刪除索引。
min_age通常是從建立索引的時間開始經過的時間。如果索引被翻轉，那麼min_age是從索引翻轉開始經過的時間。這裡的目的是執行以下階段和操作，這些階段和操作相對於資料最後寫入滾動索引的時間。
在索引生命週期管理將檢查min_age 並轉換到下一階段之前，必須完成上一階段的操作。
Phase Execution（階段執行）
正在執行的索引策略的當前階段定義儲存在索引的後設資料中。階段及其動作被編譯成一系列按順序執行的離散步驟。由於某些ILM操作更復雜並且涉及針對索引的多個操作，因此這些操作中的每一個都在稱為“步驟”的單元中單獨完成。該 解釋生命週期API公開這些資訊給我們，看看哪些步驟我們的索引或者接下來執行或正在執行。
Actions（操作）
下列清單展示每個階段可配置的動作。
在每個階段中執行已配置操作的順序由ILM自動確定，並且無法通過更改策略定義進行更改。
熱階段（Hot）
溫階段（Warm）
冷階段（Cold）
刪除階段（Delete）
Allocate
階段允許：warm，cold
Allocate操作允許您指定允許哪些節點託管索引的分片並設定副本數。在這些場景背後，它正在修改分片過濾和/或副本計數的索引設定。更新副本數時，配置分配規則是可選的。配置分配規則時，設定副本數是可選的。雖然此操作可以視為兩個單獨的索引設定更新，但兩者都可以一次配置。
配置選項
| Name | Required | Default | Description |
|---|---|---|---|
number_of_replicas |
no | - | The number of replicas to assign to the index |
include |
no | - | assigns an index to nodes having at least one of the attributes |
exclude |
no | - | assigns an index to nodes having none of the attributes |
require |
no | - | assigns an index to nodes having all of the attributes |
如果number_of_replicas未配置，那麼include， exclude和require中的至少一個是必需的。沒有配置的空Allocate Action是無效的。
示例：更改副本
在此示例中，索引的副本數已更改為2，而分配規則未更改。
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"warm": {
"actions": {
"allocate" : {
"number_of_replicas" : 2
}
}
}
}
}
}
Delete
階段允許：delete
刪除操作就是這樣，它會刪除索引。
此操作沒有與之關聯的任何選項。
示例
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"delete": {
"actions": {
"delete" : { }
}
}
}
}
}
Force-Merge
階段允許：delete
執行此操作時，索引將變成只讀。請參考
強制合併操作Force Merge會將索引合併為最多特定數量的segments。
配置選項
| 名稱 | 是否必須 | 預設 | 描述 |
|---|---|---|---|
max_num_segments |
是 | - | 要合併的段數。要完全合併索引，請將其設定為1 |
示例
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"warm": {
"actions": {
"forcemerge" : {
"max_num_segments": 1
}
}
}
}
}
}
Freeze
階段允許：cold
該動作將通過呼叫Freeze Index API的api來freeze索引
凍結索引將關閉索引並在同一API呼叫中重新開啟它。
這導致初選不能在短時間內分配
導致群集變紅，直到再次分配原色。
將來可能會刪除此限制。
示例
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"cold": {
"actions": {
"freeze" : { }
}
}
}
}
}
Read-Only
階段允許：warm
此操作將索引設定為只讀（請參閱：index.blocks.write）
此操作沒有與之關聯的任何選項。
示例
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"warm": {
"actions": {
"readonly" : { }
}
}
}
}
}
Rollover
階段允許：hot
- 索引格式必須匹配模式^。* - \ d + $，例如（
logs-000001）。 - 託管的索引必須設定
index.lifecycle.rollover_alias為別名進行Rollover，且索引還必須是以別名的寫入。
例如，如果要管理的索引具有別名my_data。託管的索引“my_index”必須是別名的寫入索引。有關更多資訊，請閱讀 寫入索引別名行為。
PUT my_index
{
"settings": {
"index.lifecycle.name": "my_policy",
"index.lifecycle.rollover_alias": "my_data"
},
"aliases": {
"my_data": {
"is_write_index": true
}
}
}
當現有索引滿足其中一個滾動更新條件時，“Rollover Action”會將別名轉到新索引。
配置選項
| Name | Required | Default | Description |
|---|---|---|---|
max_size |
no | - | 最大主分片索引儲存大小。請參見位元組單位 以進行格式化 |
max_docs |
no | - | 滾動前索引要包含的最大文件數。 |
max_age |
no | - | 索引建立過去的最長時間。請參閱 時間單位 以進行格式 |
中的至少一個max_size，max_docs，max_age或需要這三者的任意組合來進行指定。
示例：索引過大時滾動
此示例在至少100千兆位元組時滾動索引。
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"hot": {
"actions": {
"rollover" : {
"max_size": "100GB"
}
}
}
}
}
}
示例：索引包含太多文件時滾動
此示例在包含至少100000000個文件時將索引翻轉。
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"hot": {
"actions": {
"rollover" : {
"max_docs": 100000000
}
}
}
}
}
}
示例：索引太舊時滾動
此示例至少在7天前建立索引。
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"hot": {
"actions": {
"rollover" : {
"max_age": "7d"
}
}
}
}
}
}
示例：索引太舊或太大時的翻轉
此示例在至少7天前建立索引或至少100千兆位元組時將索引捲起。在這種情況下，當滿足任何條件時，索引將被翻轉。
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"hot": {
"actions": {
"rollover" : {
"max_age": "7d",
"max_size": "100GB"
}
}
}
}
}
}
Set-Priority
階段允許: hot, warm, cold.
一旦策略進入hot，warm或cold階段，此操作就會為索引設定索引優先順序。具有較高優先順序的索引將在節點重啟後具有較低優先順序的索引之前恢復。通常，hot階段的指數應具有最高值，而cold階段的指數應具有最低值。例如：hot階段設定為100，warm階段設定為50，cold階段設定為0。未設定此值的指標的預設優先順序為1。
配置選項
| 名稱 | 需要 | 預設 | 描述 |
|---|---|---|---|
priority |
是 | - | 索引的優先順序。必須為0或更大。該值也可以設定為null以刪除優先順序。 |
示例
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"warm": {
"actions": {
"set_priority" : {
"priority": 50
}
}
}
}
}
}
Shrink
執行此操作時，索引將變為只讀（請參閱：index.blocks.write）
此操作會將現有索引縮減為具有較少主分片的新索引。它呼叫Shrink API來縮小索引。由於將索引的所有主分片分配給一個節點是先決條件，因此該操作將首先將主分片分配給有效節點。收縮後，它會將指向原始索引的別名交換到新的收縮指數中。新索引還將有一個新名稱：“shrink-
配置選項
| 名稱 | 需要 | 預設 | 描述 |
|---|---|---|---|
number_of_shards |
是 | - | 要縮小的分片數。必須是源索引中分片數量的一個因子。 |
示例
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"warm": {
"actions": {
"shrink" : {
"number_of_shards": 1
}
}
}
}
}
}
Unfollow
此操作可以顯式使用，如下所示，但此操作也在Rollover操作和Shrink操作之前執行，如這些操作的文件中所述。
取消關注操作沒有任何選項，如果遇到非關注者索引，則取消關注操作會保持索引不變，並允許下一個操作對此索引進行操作。
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"hot": {
"actions": {
"unfollow" : {}
}
}
}
}
}
完整策略（Full Policy）
通過所有這些操作，我們可以為我們的索引支援複雜的管理策略。此策略將定義一個將在熱階段開始的索引，每50 GB或7天滾動一次。30天后，它進入溫暖階段並將副本增加到2，強制合併和收縮。60天后進入冷期並分配到“冷”節點，90天后刪除索引。
PUT _ilm/policy/full_policy
{
"policy": {
"phases": {
"hot": {
"actions": {
"rollover": {
"max_age": "7d",
"max_size": "50G"
}
}
},
"warm": {
"min_age": "30d",
"actions": {
"forcemerge": {
"max_num_segments": 1
},
"shrink": {
"number_of_shards": 1
},
"allocate": {
"number_of_replicas": 2
}
}
},
"cold": {
"min_age": "60d",
"actions": {
"allocate": {
"require": {
"type": "cold"
}
}
}
},
"delete": {
"min_age": "90d",
"actions": {
"delete": {}
}
}
}
}
}
參考
結語
歡迎關注微信公眾號『碼仔zonE』，專注於分享Java、雲端計算相關內容，包括SpringBoot、SpringCloud、微服務、Docker、Kubernetes、Python等領域相關技術乾貨，期待與您相遇！
