ES中的索引生命周期管理

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了ES中的索引生命周期管理相关的知识,希望对你有一定的参考价值。

参考技术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

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

一般来说,热阶段的索引应该有最高值,冷阶段的索引应该有最低值。例如: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_dateindex.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_preferencedata_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" :  
        
      
    
  

以上是关于ES中的索引生命周期管理的主要内容,如果未能解决你的问题,请参考以下文章

ES实战索引生命周期管理

ES实战索引生命周期管理

ES实战索引生命周期管理

ES索引生命周期管理

ES 索引生命周期管理策略

ES 索引生命周期管理策略