Allocate
官网文档链接:Allocate | Elasticsearch Guide [7.12] | Elastic
Allocate允许的阶段:warm,cold;
更新索引设置以更改允许托管索引分片的节点并更改副本数量。
hot阶段不允许进行Allocate操作。索引的初始分配必须手动或通过Index templates | Elasticsearch Guide [7.12] | Elastic完成
您可以配置此操作以同时修改分配规则和副本数量、仅修改分配规则或仅修改副本数量。有关 Elasticsearch 如何使用副本进行扩展的更多信息,请看:Scalability and resilience: clusters, nodes, and shards | Elasticsearch Guide [7.12] | Elastic
查阅Index-level shard allocation filtering | Elasticsearch Guide [7.12] | Elastic,了解有关控制 Elasticsearch 分配特定索引分片的位置的更多信息。
选项(Options)
必须指定Number of replicas或至少一个include、exclude或require选项。空分配操作无效
有关使用自定义属性进行分片分配的更多信息,请参阅 Index-level shard allocation filtering | Elasticsearch Guide [7.12] | Elastic
- number_of_replicas:(可选,整型)指定给index 的副本数;
- include:(可选,对象(object))将index 分配给至少具有一个指定自定义属性的节点;
- exclude:(可选,对象(object))将index分配给不具有任何指定自定义属性的节点;
- require:(可选,对象(object))将索引分配给具有所有指定自定义属性的节点;
样例(Example)
修改副本数
以下策略中的分配操作将索引的副本数更改为 2。索引分配规则不变
PUT _ilm/policy/my_policy { "policy": { "phases": { "warm": { "actions": { "allocate" : { "number_of_replicas" : 2 } } } } } }
将索引分配给特定节点并更新副本设置(Assign index to a specific node and update replica settings)
以下策略中的分配操作将索引分配给 box_type 为 hot 或 Warm 的节点
要指定(designate)节点的 box_type,您可以在节点配置中设置自定义属性。例如,在elasticsearch.yml中设置node.attr.box_type: hot。有关更多信息,请参阅Index-level shard allocation filtering | Elasticsearch Guide [7.12] | Elastic
PUT _ilm/policy/my_policy { "policy": { "phases": { "warm": { "actions": { "allocate" : { "include" : { "box_type": "hot,warm" } } } } } } }
根据多个属性为节点分配索引(Assign index to nodes based on multiple attributes)
allocate 操作还可以根据多个节点属性为节点分配索引。以下操作根据 box_type 和Storage节点属性分配索引
PUT _ilm/policy/my_policy { "policy": { "phases": { "cold": { "actions": { "allocate" : { "require" : { "box_type": "cold", "storage": "high" } } } } } } }
将索引分配给特定节点并更新副本设置(Assign index to a specific node and update replica settings)
以下策略中的分配操作将索引更新为每个分片有一个副本,并分配给 box_type 为 Cold 的节点。
要指定节点的 box_type,您可以在节点配置中设置自定义属性。例如,在elasticsearch.yml中设置node.attr.box_type:cold。有关更多信息,请参阅Index-level shard allocation filtering | Elasticsearch Guide [7.12] | Elastic。
PUT _ilm/policy/my_policy { "policy": { "phases": { "warm": { "actions": { "allocate" : { "number_of_replicas": 1, "require" : { "box_type": "cold" } } } } } } }
Delete
官网文档链接:Delete | Elasticsearch Guide [7.12] | Elastic
Delete允许的阶段: delete。
永久删除index;
选项(Options)
- delete_searchable_snapshot:(可选,布尔值)删除在上一阶段创建的可搜索快照。默认为 true。当在任何先前阶段使用Searchable snapshot | Elasticsearch Guide [7.12] | Elastic操作时,此选项适用
样例(Example)
PUT _ilm/policy/my_policy { "policy": { "phases": { "delete": { "actions": { "delete" : { } } } } } }
Force merge
官方文档链接:Force merge | Elasticsearch Guide [7.12] | Elastic
Force merge 允许的阶段:hot,warm
Force merge API | Elasticsearch Guide [7.12] | Elastic 指定索引最大的段数。此操作使索引变为Index modules | Elasticsearch Guide [7.12] | Elastic
要在hot阶段使用force merge操作,必须存在rollover操作。如果未配置rollover操作,ILM 将拒绝该策略。
NOTE:Forcemerge 操作是尽力而为(best effort)。可能会发生某些分片正在重新定位的情况,在这种情况下它们将不会被合并。
选项(Options)
- max_num_segments:必需,整数)要合并到的段数。要完全合并索引,请设置为 1。
- index_codec:(可选,字符串)用于压缩文档存储的编解码器。唯一接受的值是 best_compression,它使用 DEFLATE 获得更高的压缩比,但存储字段性能更慢,要使用默认的 LZ4 编解码器,请省略此参数。
WARNING:如果使用 best_compression,ILM 将在强制合并之前关闭并重新打开索引。关闭时,索引将不可用于读取或写入操作。
样例(Example)
PUT _ilm/policy/my_policy { "policy": { "phases": { "warm": { "actions": { "forcemerge" : { "max_num_segments": 1 } } } } } }
Freeze
官网文档链接:Freeze | Elasticsearch Guide [7.12] | Elastic
Freeze允许的阶段:cold
Frozen indices 以最大限度减少内存占用。
IMPORTANT: freezing index 会关闭索引并在同一 API 调用中重新打开它。这意味着短时间内不会分配primaries shard。集群将变为红色,直到分配primaries shard为止。此限制将来可能会被删除
样例(Example)
PUT _ilm/policy/my_policy { "policy": { "phases": { "cold": { "actions": { "freeze" : { } } } } } }
Migrate
官网链接:Migrate | Elasticsearch Guide [7.12] | Elastic
Migrate允许的阶段:warm,cold;
通过更新index.routing.allocation.include._tier_preference设置将索引移动到与当前阶段对应的数据层,如果分配操作未指定分配选项,ILM 会在warm阶段和cold阶段自动注入迁移操作,如果指定仅修改索引副本数量的分配操作,ILM 会在迁移索引之前减少副本数量。要防止在不指定分配选项的情况下自动迁移,您可以显式包含迁移操作并将启用选项设置为 false。
如果冷阶段定义了Searchable snapshot | Elasticsearch Guide [7.12] | Elastic操作,则迁移操作不会在冷阶段自动注入,因为托管索引将使用迁移操作配置的相同 _tier_preference 基础设施直接安装在目标层上
在warm阶段,迁移操作将index.routing.allocation.include._tier_preference设置为data_warm,data_hot。这会将索引移动到的warm tier,节点如果warm tier中没有节点,则回退到hot tier
在cold阶段,迁移操作将index.routing.allocation.include._tier_preference设置为data_cold、data_warm、data_hot。这会将索引移动到cold tier的节点。如果cold tier没有节点,则回退到warm tier;如果没有可用的warm tier ,则回退到hot tier。
frozen阶段不允许进行migrate动作,freeze阶段直接使用data_frozen,data_cold,data_warm,data_hot的index.routing.allocation.include._tier_preference挂载可搜索快照,这会将索引移动到frozen tier的节点。如果frozen tier 没有节点,则它会回退到cold tier ,然后是warm tier,最后是hot tier。
Hot阶段不允许进行迁移操作。初始索引分配是自动执行的,可以手动或通过index template进行配置。
选项(Options)
- enabled:可选,布尔值)控制 ILM 是否在此阶段自动迁移索引。默认为 true
样例(Example)
在以下策略中,指定分配操作以在 ILM 将索引迁移到warm节点之前减少副本数量
NOTE: 不需要显式指定迁移操作 - ILM 会自动执行迁移操作,除非您指定分配选项或禁用迁移。
PUT _ilm/policy/my_policy { "policy": { "phases": { "warm": { "actions": { "migrate" : { }, "allocate": { "number_of_replicas": 1 } } } } } }
Disable automatic migration
以下策略中的迁移操作被禁用,分配操作将索引分配给rack_id 为1 或2 的节点。
NOTE:不需要显式禁用迁移操作 - 如果您指定Allocate选项,ILM 不会注入迁移操作
# 那为啥在这个案例里面显式的指明禁用migrate了? PUT _ilm/policy/my_policy { "policy": { "phases": { "warm": { "actions": { "migrate" : { "enabled": false }, "allocate": { "include" : { "rack_id": "one,two" } } } } } } }
migrate 和allocate 的区别是什么?
我觉得可能migrate 是需要和index.routing.allocation.include._tier_preference一起使用的,并且集群中要有不同觉得的data node ,比如data_warm,data_cold,data_hot等等,而allocate可以和这上述一起使用,但可能不是必须得。
Read only
官网链接:Read only | Elasticsearch Guide [7.12] | Elastic
read only 允许的阶段:hot,warm,cold;
使索引read only
要在hot阶段使用read only操作,必须存在rollover操作。如果未配置rollover操作,ILM 将拒绝该策略.
样例(Example)
PUT _ilm/policy/my_policy { "policy": { "phases": { "warm": { "actions": { "readonly" : { } } } } } }
Rollover
rollover允许的阶段:hot
当现有index 满足roll over(滚动更新)条件之一是,将目标index 滚动到新索引。
IMPORTANT:如果对follower index使用翻转操作,则策略执行将等到leader index翻转(或以其他方式标记为完成),然后使用unfollow 操作将follower index转换为regular索引。
什么是follower index ?
一个rollover 目标可以是data stream 或者是一个index alias,当目标是一个data stream 新的index成为data stream的写入index 并且它的生成是递增的。
为了rollover一个index alias,alias 和它的写入索引必须满足如下条件:
- index name 必须匹配模式 ^.*-\d+$,例如(my-index-000001)
- index.lifecycle.rollover_alias 必须配置为roll over 的alias。
- index 必须是alias 的 写入index;
例如,如果my-index-000001有一个 alias my_data, 如下设置必须配置:
PUT my-index-000001
{
"settings": {
"index.lifecycle.name": "my_policy",
"index.lifecycle.rollover_alias": "my_data"
},
"aliases": {
"my_data": {
"is_write_index": true
}
}
}
选项(Options)
你必须指定至少一个rollover 条件,一个空rollover action是无效的。
- max_age: 可选,时间单位)达到索引创建后的最大经过(elapsed)时间后触发滚动.始终从索引创建时间开始计算经过的时间,即使索引起始(origination)日期配置为自定义日期,例如使用index.lifecycle.parse_origination_date或index.lifecycle.origination_date设置时
- max_docs: (可选,整数)在达到指定的最大文档数后触发滚动。自上次refresh后添加的文档不包含在文档计数中。文档计数不包括副本分片中的文档。
- max_size: (可选,字节单位)当索引达到一定大小时触发翻转。这是索引中所有主分片的总大小。副本不计入最大索引大小。
TIP:要查看当前索引大小,请使用 _cat index API。 pri.store.size 值显示所有主分片的组合大小。
样例(Example)
Roll over based on index size
此示例在索引至少达到 100 GB 时滚动索引。
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"hot": {
"actions": {
"rollover" : {
"max_size": "100GB"
}
}
}
}
}
}
Roll over based on document count
此示例在索引包含至少一亿个文档时滚动索引。
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"hot": {
"actions": {
"rollover" : {
"max_docs": 100000000
}
}
}
}
}
}
Roll over based on index age
如果索引至少是 7 天前创建的,则此示例将滚动该索引。
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"hot": {
"actions": {
"rollover" : {
"max_age": "7d"
}
}
}
}
}
}
Roll over using multiple conditions
当您指定多个滚动条件时,只要满足任何一个条件,索引就会滚动。如果索引至少存在 7 天或至少 100 GB,则此示例将滚动索引
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"hot": {
"actions": {
"rollover" : {
"max_age": "7d",
"max_size": "100GB"
}
}
}
}
}
}
Rollover condition blocks phase transition
仅当满足其条件之一时,翻转操作才会完成。这意味着任何后续阶段都会被阻止,直到翻转成功。
例如,以下策略会在索引滚动一天后删除该索引。它不会在索引创建一天后删除该索引。
PUT /_ilm/policy/rollover_policy
{
"policy": {
"phases": {
"hot": {
"actions": {
"rollover": {
"max_size": "50G"
}
}
},
"delete": {
"min_age": "1d",
"actions": {
"delete": {}
}
}
}
}
}
Searchable snapshot
允许的阶段:hot, cold, frozen.
拍摄已配置存储库中托管索引的快照并将其安装为可搜索快照。如果索引是数据流的一部分,则安装的索引将替换流中的原始索引。
searchable_snapshot 操作需要数据层。该操作使用index.routing.allocation.include._tier_preference设置将索引直接安装到阶段的相应数据层,在冻结阶段,该操作使用共享缓存挂载选项将可搜索快照索引挂载到冻结层。在其他阶段,该操作将可搜索快照索引的完整副本安装到相应的数据层。
IMPORTANT:如果在hot阶段使用 searchable_snapshot 操作,则后续阶段无法定义任何shrink、force merge、freeze或 searchable_snapshot(在冷和冻结阶段也可用)操作。
NOTE:无法对数据流的写入索引执行此操作。这样做的尝试将会失败。要将索引转换为可搜索快照,首先手动滚动数据流。这会创建一个新的写入索引。于索引不再是流的写入索引,因此该操作可以将其转换为可搜索的快照。使用在hot阶段使用rollover操作的策略将避免这种情况以及对未来管理index进行手动rollover的需要。
默认情况下,该快照会被删除阶段的删除操作删除。要保留快照,请在删除操作中将 delete_searchable_snapshot 设置为 false
选项(Options)
- snapshot_repository:必需,字符串)指定存储快照的位置。有关详细信息,请参阅注册存储库。在non-frozen阶段,快照将作为 full_copy 挂载,而在frozen阶段,将使用 share_cache 存储类型挂载。
- force_merge_index: (可选,布尔值)强制将托管索引合并到一个段。默认为 true。如果托管索引已使用先前操作中的强制合并操作进行强制合并,则可搜索快照操作强制合并步骤将是无操作。
NOTE: Forcemerge 操作是尽力而为。可能会发生某些分片正在重新定位的情况,在这种情况下它们将不会被合并。即使并非所有分片都被强制合并,searchable_snapshot 操作也会继续执行
样例(EXamples)
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"cold": {
"actions": {
"searchable_snapshot" : {
"snapshot_repository" : "backing_repo"
}
}
}
}
}
}
Set priority
允许阶段:hot,warm,cold。
一旦策略进入hot、warm或cold阶段,就设置索引的优先级。节点重启后,优先级较高的索引先于优先级较低的索引恢复。
一般情况下,hot 阶段的index应取最高值,cold 阶段index 应取最低值。例如:100 为hot阶段,50 为warm阶段,0 为cold阶段。未设置此值的索引的默认优先级为 1。
选项(Options)
- priority:(必需,整数)索引的优先级。必须为 0 或更大。设置为 null 以删除优先级。
样例(Example)
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"warm": {
"actions": {
"set_priority" : {
"priority": 50
}
}
}
}
}
}
Shrink
允许的阶段:hot,warm
将索引设置为只读并将其收缩为主分片更少的新索引。新索引的名称格式为shrink-<original-index-name>。例如,如果源索引的名称为logs,则收缩索引的名称为shrink-logs。收缩操作将索引的所有主分片分配给一个节点,以便它可以调用Shrink API来收缩索引。收缩后,它将指向原始索引的别名交换到新的收缩索引
要在热阶段使用收缩动作,必须存在翻转动作。如果未配置滚动操作,ILM 将拒绝该策略。
IMPORTANT:如果对跟随者索引使用收缩操作,则策略执行将等待,直到领导者索引滚动(或以其他方式标记为完成),然后在执行收缩操作之前,通过 unfollow 操作将关注者索引转换为常规索引。
如果托管索引是数据流的一部分,则缩小的索引将替换数据流中的原始索引
NOTE:无法对数据流的写入索引执行此操作。这样做的尝试将会失败。要收缩索引,首先手动滚动数据流。这会创建一个新的写入索引。这将创建一个新的写入索引。因为该索引不再是流的写入索引,所以该操作可以恢复缩小它。使用在热阶段使用展期操作的策略将避免这种情况以及对未来管理指数进行手动展期的需要。
选项(shrink Options)
- number_of_shards:可选,整数)要缩小到的分片数量。必须是源索引中分片数量的一个因素。该参数与max_primary_shard_size冲突,只能设置其中之一。
- max_primary_shard_size:(可选,字节单位)目标索引的最大主分片大小。用于寻找目标索引的最佳分片数量。设置该参数后,每个分片在目标索引中的存储不会大于该参数。目标索引的分片计数仍将是源索引分片计数的一个因素,但如果该参数小于源索引中的单个分片大小,则目标索引的分片计数将等于源索引的分片计数。例如,当该参数设置为50GB时,如果源索引有60个主分片,总计100GB,则目标索引将有2个主分片,每个分片大小为50GB。如果源索引有 60 个主分片,总计 1000GB,则目标索引将有 20 个主分片;如果源索引有 60 个主分片,总计 4000GB,则目标索引仍将有 60 个主分片。该参数与设置中的number_of_shards冲突,只能设置其中之一。
样例(Example)
Set the number of shards of the new shrunken index explicitly
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"warm": {
"actions": {
"shrink" : {
"number_of_shards": 1
}
}
}
}
}
}
Calculate the optimal number of primary shards for a shrunken index
以下策略使用 max_primary_shard_size 参数根据源索引的存储大小自动计算新收缩索引的主分片计数。
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"warm": {
"actions": {
"shrink" : {
"max_primary_shard_size": "50gb"
}
}
}
}
}
}
Unfollow
允许的阶段:hot, warm,cold,frozen
转换一个跨集群副本(CCR)follower index为常规index。这使得能够在follower index上安全地执行shrink、rollover和searchable snapshot操作。在生命周期中移动follower index时,您还可以直接使用 unfollow。对非follower的index没有影响,阶段执行只是转到下一个操作。
NOTE:当rollover、shrink和searchable snapshop操作应用于follower index时,会自动触发此操作。
此操作会等到可以安全地将follover转换为regular index为止。必须满足以下条件:
-
leader index 必须将 index.lifecycle.indexing_complete 设置为 true。如果使用rollover操作滚动leader index,则会自动发生这种情况,并且可以使用索引设置 API 手动设置。
-
对leader index执行的所有操作都已复制到follower index。这确保了索引转换时不会丢失任何操作。
一旦满足这些条件,unfollow 就会执行以下操作:
- 暂停 indexing following 为follower index;
- 关闭follower index;
- unfollow leader index;
- 打开 follower index(此时已经是regular index)
样例(Example)
PUT _ilm/policy/my_policy { "policy": { "phases": { "hot": { "actions": { "unfollow" : {} } } } } }
Wait for snapshot
允许的阶段:delete
删除索引之前等待执行指定的 SLM(snapshot lifecycle mangement) 策略,这确保了已删除索引的快照可用
Options
- policy:(必需,字符串)删除操作应等待的 SLM 策略的名称。
Example
PUT _ilm/policy/my_policy { "policy": { "phases": { "delete": { "actions": { "wait_for_snapshot" : { "policy": "slm-policy-name" } } } } } }