概述
本文是在本人學習研究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等領域相關技術干貨，期待與您相遇！
