ES-7.12.0-官网阅读-Index lifecycle actions各action详解

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"
          }
        }
      }
    }
  }
}

上一篇:Ubuntu 如何移动硬盘在所有账号都分享


下一篇:Ubuntu 20.04 LTS 在3588安卓主板上测试yolov8-1.0版本的yolov8n-seg模型