ES中的索引生命周期管理

Posted 2023-04-19

参考技术A ILM ：索引生命周期管理，即 Manage the index lifecycle 。

索引的生命周期有四个阶段：

索引的生命周期策略指定了适用于哪些阶段、在每个阶段中执行哪些操作以及何时在各个阶段之间进行转换。

当索引满足一定条件之后，将不再写入数据，而是自动创建一个索引，所有的数据将写入新的索引。

使用滚动索引能够：

官方推荐使用 data stream 数据流来管理时间序列数据。每个数据流都需要一个 索引模板 ，其中包括：

数据流专为追加数据而设计，其中数据流名称可用作操作（读取、写入、翻转、收缩等）目标。如果需要更新数据，可以使用 索引别名 来管理时间序列数据。

ILM 会根据你的配置： 索引大小 、 文档数量 、 所在阶段 ，当满足这些条件时，自动实现 rollover 。

要让 ILM 管理索引，必须要在 index.lifecycle.name 索引设置中指定有效的策略。

要为滚动索引创建生命周期策略，你要创建该策略并把它加入到 索引模板 中。

可以通过 Kibana 管理页面设置，也可以通过API设置。

可以通过 Kibana 管理页面设置，也可以通过API设置。

如果要给滚动索引设置策略，需要手动创建第一个被该策略管理的索引，并指定为可写索引。

索引的名称必须跟索引模板里定义的模式相匹配，并且以数字结尾。

你可以在创建索引的时候指定一个策略，也可以直接将策略应用到一个已经存在的索引上通过 Kibana 管理或者更新设置的API。一旦你应用了策略， ILM 立即会开始管理该索引。

查看错误：

重新运行报错的一步：

查看 ILM 状态：

终止 ILM ：

开启 ILM ：

设置 index.lifecycle.indexing_complete 为 true 。

举个例子，如果你要改变一系列新索引的名称，并保留之前根据你配置的策略产生的索引数据，你可以：

相关连接： https://www.elastic.co/guide/en/elasticsearch/reference/7.9/index-lifecycle-management.html

获取最新文章，可关注博客地址： https://jenkinwang.github.io/

ES实战索引生命周期管理

生命周期中的操作

文章目录

• 生命周期中的操作
• • Set Priority
  • Unfollow
  • Freeze -- 版本之后8.0开始取消
  • Rollover
  • Read-Only
  • Shrink
  • Force Merge
  • Searchable Snapshot
  • Downsample
  • Allocate
  • Migrate
  • Wait For Snapshot
  • Delete

Set Priority

一旦策略进入热、暖或冷阶段，就设置索引的优先级。在节点重启后，优先级较高的索引会在优先级较低的索引之前被恢复。

一般来说，热阶段的索引应该有最高值，冷阶段的索引应该有最低值。例如：HOT阶段为100，Warm阶段为50，cold阶段为0。没有设置这个值的索引，其默认的优先级为1。

PUT _ilm/policy/my_policy

  "policy": 
    "phases": 
      "warm": 
        "actions": 
          "set_priority" : 
            "priority": 50
          
        
      
    
  

Unfollow

将CCR跟随者索引转换为普通索引。这使得shrink、rollover和searchable snapshot等操作可以在跟随者索引上安全地执行。当在生命周期中移动跟随者索引时，你也可以直接使用unfollow。对不是跟随者的索引没有影响，阶段执行只是移动到下一个动作。

PUT _ilm/policy/my_policy

  "policy": 
    "phases": 
      "hot": 
        "actions": 
          "unfollow" : 
        
      
    
  

Freeze – 版本之后8.0开始取消

冻结一个索引以减少其内存占用。

PUT _ilm/policy/my_policy

  "policy": 
    "phases": 
      "cold": 
        "actions": 
          "freeze" :  
        
      
    
  

Rollover

当现有的索引满足滚动条件之一时，将一个目标翻转到一个新的索引。

如果在跟随者索引上使用滚动动作，策略的执行会等待，直到领导者索引滚动（或以其他方式标记完成），然后用取消关注动作将跟随者索引转换为普通索引。

翻转目标可以是一个数据流或一个索引别名。当以数据流为目标时，新的索引成为数据流的写索引，其生成被递增。

要翻转一个索引别名，该别名和它的写索引必须满足以下条件:

• 索引名称必须符合模式^.*-\\d+$，例如（my-index-000001）
• index.lifecycle.rollover_alias必须被配置为要翻转的别名
• 索引必须是该别名的写入索引

如果 my-index-000001 拥有索引别名 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
    
  

必须指定至少一个翻转条件。一个空的翻转动作是无效的。可选条件如下：

• max_age
  (可选的，时间单位）在达到从索引创建开始的最大经过时间后，触发滚动。经过的时间总是从索引创建时间开始计算，即使索引的起始日期被配置为一个自定义日期（通过index.lifecycle.parse_origination_date或index.lifecycle.origination_date设置）。
• max_docs
  (可选的，整数）在达到指定的最大文档数量后触发翻转。上次刷新后添加的文档不包括在文档计数中。文档计数不包括副本分片中的文档。
• max_size
  (可选的，以字节为单位）当索引达到一定的大小时，触发器会翻转。这是索引中所有主分片的总大小。复制不会被计入最大的索引大小。

PUT _ilm/policy/my_policy

  "policy": 
    "phases": 
      "hot": 
        "actions": 
          "rollover" : 
            "max_age": "7d",
            "max_size": "100GB"
            "max_docs": 100000000
          
        
      
    
  

翻转动作只有在满足其条件之一的情况下才会完成。这意味着任何后续阶段都被阻断，直到翻转成功。 翻转条件会阻碍了阶段转换

Read-Only

使得索引成为只读。

要在热阶段使用只读动作，必须有翻转动作。如果没有配置翻转动作，ILM将拒绝该策略。

PUT _ilm/policy/my_policy

  "policy": 
    "phases": 
      "warm": 
        "actions": 
          "readonly" :  
        
      
    
  

Shrink

将一个索引设置为只读，并将其收缩为一个具有较少主分片的新索引。新索引的名称是shrink-<original-index-name>的形式。例如，如果源索引的名字是logs，缩减后的索引的名字是shrink-logs。

shrink动作将索引的所有主分片分配给一个节点，这样它就可以调用Shrink API来收缩索引。在收缩之后，它将指向原始索引的别名交换到新的收缩后的索引。

要在热阶段使用收缩动作，必须有翻转动作。如果没有配置翻转动作，ILM将拒绝该策略。

如果在跟随者索引上使用收缩操作，策略的执行会等待领导者索引翻转（或者以其他方式标记完成），然后在执行收缩操作之前，用取消跟随操作将跟随者索引转换为普通索引。

如果被管理的索引是数据流的一部分，收缩后的索引将取代数据流中的原始索引。

这个操作不能在数据流的写索引上执行。试图这样做会失败。要收缩索引，首先手动翻转数据流。这将创建一个新的写索引。因为该索引不再是数据流的写索引，该操作可以恢复收缩它。使用在热阶段利用翻转动作的策略将避免这种情况，以及对未来管理索引进行手动翻转的需要。

PUT _ilm/policy/my_policy

  "policy": 
    "phases": 
      "warm": 
        "actions": 
          "shrink" : 
            "number_of_shards": 1
          
        
      
    
  

Force Merge

强制将索引合并到指定的最大段数中。这个动作使索引成为只读的。

要在热阶段使用forcemerge动作，必须有rollover动作。如果没有配置翻转动作，ILM将拒绝该策略。

forcemerge动作是最好的努力。可能会发生一些分片正在重新定位，在这种情况下，它们将不会被合并。

PUT _ilm/policy/my_policy

  "policy": 
    "phases": 
      "warm": 
        "actions": 
          "forcemerge" : 
            "max_num_segments": 1
          
        
      
    
  

Searchable Snapshot

在配置的资源库中获取管理的索引的快照，并将其挂载为可搜索的快照。如果该索引是数据流的一部分，被挂载的索引将取代数据流中的原始索引。

searchable_snapshot 操作需要数据层。该操作使用index.routing.allocation.include._tier_preference设置来将索引直接挂载到该阶段相应的数据层。例如，在冷阶段，该操作将可搜索快照索引挂载到冷数据层。

PUT _ilm/policy/my_policy

  "policy": 
    "phases": 
      "cold": 
        "actions": 
          "searchable_snapshot" : 
            "snapshot_repository" : "backing_repo"
          
        
      
    
  

如果在热阶段使用了 searchable_snapshot 动作，后续阶段就不能定义任何shrink, forcemerge, freeze or searchable_snapshot（在冷阶段也可用）操作。

这个操作不能在数据流的写索引上执行。试图这样做会失败。要将索引转换为可搜索的快照，首先手动翻转数据流。这将创建一个新的写索引。因为该索引不再是数据流的写索引，该操作可以将其转换为可搜索快照。使用一个在热阶段利用翻转动作的策略将避免这种情况，以及对未来管理索引进行手动翻转的需要。

默认情况下，该快照被删除阶段中的删除操作所删除。要保留快照，请在删除操作中把delete_searchable_snapshot设置为false。

Downsample

聚集一个时间序列（TSDS）索引，并存储预先计算的统计摘要（最小、最大、总和、值_计数和平均数），用于按配置的时间间隔分组的每个指标领域。例如，一个包含每10秒取样的指标的TSDS索引可以被降频为每小时索引。一小时间隔内的所有文件都被汇总并作为一个文件存储，并存储在向下采样索引中。

这个操作对应的是downsample API。

产生的下采样索引的名称是downsample-<original-index-name>-<random-uuid>。如果ILM对一个数据流的支持索引执行了downsample操作，那么downsample索引就会成为同一数据流的支持索引，而源索引则被删除。

要在热阶段使用downsample动作，必须有rollover动作。如果没有配置翻转动作，ILM将拒绝该策略。

PUT _ilm/policy/datastream_policy

  "policy": 
    "phases": 
      "hot": 
        "actions": 
          "rollover": 
            "max_docs": 1
          ,
          "downsample": 
  	          "fixed_interval": "1h"
  	      
        
      
    
  

• fixed_interval：(必填, 字符串) 将对数据进行下采样的固定时间间隔。

Allocate

更新索引设置，以改变哪些节点被允许托管索引分片，并改变副本分片的数量。索引的初始分配必须手动或通过索引模板完成。

你可以配置这个动作，同时修改分配规则和副本数量，只修改分配规则，或者只修改副本数量。分配规则采用索引级别的。

 PUT _ilm/policy/my_policy
 
   "policy": 
     "phases": 
       "cold": 
         "actions": 
           "allocate" : 
             "require" : 
               "box_type": "cold",
               "storage": "high"
             
           
         
       
     
   
 

除了require,同样支持include,exclude

Migrate

通过更新index.routing.allocation.include._tier_preference索引设置，将索引移动到与当前阶段相对应的数据层。如果没有与allocate动作一起指定分配选项，ILM就会在Warm和Cold阶段自动注入migrate动作。如果你指定了一个只修改索引副本数量的allocate动作，ILM会在迁移索引之前减少副本的数量。为了防止在不指定分配选项的情况下进行自动迁移，你可以明确地包括migrate动作，并将启用选项设置为false。

如果冷阶段定义了一个可搜索的快照动作，那么迁移动作将不会在冷阶段自动注入，因为被管理的索引将使用迁移动作配置的相同的_tier_preference基础设施直接挂载到目标层。

在Warm阶段，迁移动作将 index.routing.allocation.include._tier_preference设置为 data_warm,data_hot。这就把索引移到了Warm层的节点上。如果Warm层中没有节点，它就会返回到HOT层中。

在冷阶段，迁移动作将index.routing.allocation.include._tier_preference设置为data_cold,data_warm,data_hot。这就把索引移到了Cold层的节点上。如果Cold层中没有节点，它就会返回到Warm层，如果没有Warm层节点可用，就会返回到HOT层。

在Frozen阶段是不允许进行迁移操作的。Frozen阶段使用index.routing.allocation.include._tier_preference的 data_frozen,data_cold,data_warm,data_hot直接装载可搜索快照。这将索引移动到Frozen层的节点上。如果Frozen层中没有节点，它就会返回到Cold层，然后是Warm层，最后是Hot层。

在HOT阶段不允许进行迁移操作。最初的索引分配是自动进行的，可以手动配置或通过索引模板配置。

以下策略中的migrate动作被禁用，allocate动作将索引分配给rack_id为1或2的节点。

PUT _ilm/policy/my_policy

  "policy": 
    "phases": 
      "warm": 
        "actions": 
          "migrate" : 
           "enabled": false
          ,
          "allocate": 
            "include" : 
              "rack_id": "one,two"
            
          
        
      
    
  

Wait For Snapshot

在删除索引之前等待指定的SLM策略被执行。这确保了被删除的索引的快照是可用的。

PUT _ilm/policy/my_policy

  "policy": 
    "phases": 
      "delete": 
        "actions": 
          "wait_for_snapshot" : 
            "policy": "slm-policy-name"
          
        
      
    
  

Delete

永久性地删除索引

PUT _ilm/policy/my_policy

  "policy": 
    "phases": 
      "delete": 
        "actions": 
          "delete" :