用两行 JSON 替换你的 ILM 策略：数据流生命周期新增冻结层支持

作者：来自 Elastic Jon Avezbaki

在 Elasticsearch 9.5 中，数据流生命周期中的 frozen_after 会自动将索引迁移到对象存储上的可搜索快照中，同时保持索引可查询，并与降采样和保留策略协同工作。

在 Elasticsearch 9.5 中，数据流生命周期可以将后备索引移动到冻结层，作为对象存储上的可搜索快照，而无需配置 ILM 策略。在几行 JSON 中，将 frozen_after 添加到 data_retention 和可选的降采样旁边，或者在 Kibana 中进行设置。该功能已在 9.5 中正式发布。

如何在数据流生命周期中配置 frozen_after

frozen_after 位于生命周期的顶层，与 data_retention 和 downsampling 并列。

复制代码

PUT _data_stream/my-data-stream/_lifecycle

{
  "data_retention": "90d",
  "frozen_after": "30d"
}

在 API 层面，这就是整个功能。my-data-stream 中的索引会在热层保留 30 天，然后移动到冻结层，继续保留 60 天。90 天后，它们会被删除，相应的后备快照也会随之删除。

它可以与生命周期的其他功能组合使用，包括降采样：

复制代码

PUT _data_stream/my-data-stream/_lifecycle

{
  "data_retention": "90d",
  "frozen_after": "30d",
  "downsampling": [
    { "after": "1d", "fixed_interval": "1h" }
  ]
}

索引模板中也可以使用相同的配置：

复制代码

PUT _index_template/my-index-template

{
  "index_patterns": ["my-data-stream*"],
  "data_stream": {},
  "template": {
    "lifecycle": {
      "data_retention": "90d",
      "frozen_after": "30d"
    }
  }
}

这些值的顺序会受到强制约束：frozen_after 必须小于 data_retention，并且大于任何 downsampling.after。对于没有实际意义的配置，API 会拒绝。

冻结层数据存储在哪里：默认快照仓库

冻结层数据以部分挂载的可搜索快照形式保存，这意味着 DLM（Data Lifecycle Management）需要一个快照仓库来写入数据。9.5 引入了集群级默认快照仓库，而不再要求你为每个生命周期选择一个仓库。

复制代码

PUT _cluster/settings

{
  "persistent": {
    "repositories.default_repository": "my-snapshot-repo"
  }
}

DLM 会将这个仓库用于集群中每个冻结层索引。在 Elastic Cloud Hosted（ECH）上，默认仓库会预先设置为 found-snapshots，因此现有集群开箱即用。如果你希望将冻结数据保存在自己控制的存储桶中，也可以将其修改为你自己管理的仓库。这对于希望使用对象版本控制、将生命周期备份到 Glacier，或者其他需要存储桶级访问权限的场景很有用。

无论你在 Kibana 中哪里设置 frozen_after，界面都会直接显示当前默认仓库，并提供修改位置的链接，因此你可以清楚地看到冻结数据将写入哪里。

如果集群没有配置默认仓库，你仍然可以使用 frozen_after 创建生命周期。API 会接受该配置，但返回警告：

复制代码

{
  "acknowledged": true,
  "warnings": [
    {
      "message": "No default snapshot repository has been configured. Data will not be moved to the frozen tier until a default snapshot repository is configured."
    }
  ]
}

在配置默认仓库并且仓库可用之前，数据会一直保留在热层。如果集群没有有效的 Enterprise 许可证，也采用相同的逻辑。错误会显示在该数据流的**数据流生命周期状态 API**中。

在 Kibana 中配置 frozen_after

Kibana 9.5 允许你直接在界面中设置 frozen_after 和默认快照仓库。在 Streams 中，Retention 选项卡会在生命周期时间线上显示冻结阶段，以及热阶段和任何降采样步骤。点击时间线即可打开数据生命周期弹出窗口，设置 frozen_after，并在保存之前查看时间线更新后的效果。Index Management 的 Data Streams 页面也会打开相同的弹出窗口。

数据流生命周期中的冻结层转换如何工作

当后备索引的年龄超过 frozen_after 后，DLM 会依次执行以下五个步骤：

克隆。将索引标记为只读，并将其克隆为一个零副本副本，这样在转换过程中原始索引仍然可用。
强制合并。将克隆索引合并为单个段。完成后会写入一个集群状态标记；重复的强制合并请求，例如发生主节点故障转移之后的请求，会被去重，因此重启不会重复执行已经完成的工作。
快照。将合并后的克隆写入默认仓库，并在成功后将快照名称记录到集群状态中。如果检测到之前尝试产生的停滞快照，DLM 会将其删除并重新执行该步骤。
挂载。根据快照创建一个部分挂载的可搜索快照索引。
交换并删除。一旦挂载索引的分片全部完成分配，就在数据流中以原子方式将其替换原始索引，然后删除原始索引。交换过程是原子的，因此查询结果不会在转换过程中看到数据量下降。

如果某个步骤失败，DLM 会在下一次运行时从最后一个成功的步骤继续重试。

每个步骤都是幂等的，集群状态标记可以确保在主节点故障转移后，已经完成的工作不会被重复执行。并发转换数量会受到限制，因此即使生命周期变更覆盖数千个索引，也不会使集群不堪重负。错误会显示在**数据流生命周期状态 API**中，并汇总到生命周期健康指标中。

frozen_after 的范围和限制

仅适用于数据索引 。frozen_after 适用于数据流的数据索引。故障存储索引目前不支持冻结层，仍然由自身的 data_retention 设置管理。
需要 Enterprise 许可证 。DLM 中的冻结层通过可搜索快照实现，因此需要 Enterprise 许可证。你可以在任何许可证级别上写入 frozen_after，但在许可证有效之前，数据不会移动到冻结层。
Serverless 会忽略该字段 。在 Elastic Cloud Serverless 中，frozen_after 会被接受但被忽略 ------ Serverless 会代表你管理分层。内置模板可能包含该字段，因此系统不会拒绝它，但会跳过这一步。

开始使用 frozen_after

在 Kibana 中打开 Streams 或 Index Management，选择一个由数据流生命周期管理的数据流。
打开 Edit data lifecycle 弹出窗口，设置冻结时间，然后保存。生命周期时间线会显示新的阶段。
在自管理集群中，将 repositories.default_repository 设置为你控制的仓库。在 ECH 上，如果你希望零配置，found-snapshots 已经配置好。
对于声明式工作流，将相同的配置写入索引模板，这样新创建的数据流就会自动采用该生命周期。

了解更多

本文中所描述的任何功能或特性的发布时间和推出时间均由 Elastic 自行决定。任何当前尚未提供的功能或特性可能无法按时交付，也可能根本不会交付。

原文：Frozen tier without ILM: data stream lifecycle in Elasticsearch | Elasticsearch Labs