作者:来自 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 并列。
bash
`PUT _data_stream/my-data-stream/_lifecycle` AI写代码
json
`
1. {
2. "data_retention": "90d",
3. "frozen_after": "30d"
4. }
`AI写代码
在 API 层面,这就是整个功能。my-data-stream 中的索引会在热层保留 30 天,然后移动到冻结层,继续保留 60 天。90 天后,它们会被删除,相应的后备快照也会随之删除。
它可以与生命周期的其他功能组合使用,包括降采样:
bash
`PUT _data_stream/my-data-stream/_lifecycle` AI写代码
json
`
1. {
2. "data_retention": "90d",
3. "frozen_after": "30d",
4. "downsampling": [
5. { "after": "1d", "fixed_interval": "1h" }
6. ]
7. }
`AI写代码
索引模板中也可以使用相同的配置:
arduino
`PUT _index_template/my-index-template` AI写代码
bash
`
1. {
2. "index_patterns": ["my-data-stream*"],
3. "data_stream": {},
4. "template": {
5. "lifecycle": {
6. "data_retention": "90d",
7. "frozen_after": "30d"
8. }
9. }
10. }
`AI写代码
这些值的顺序会受到强制约束:frozen_after 必须小于 data_retention,并且大于任何 downsampling.after。对于没有实际意义的配置,API 会拒绝。
冻结层数据存储在哪里:默认快照仓库
冻结层数据以部分挂载的可搜索快照形式保存,这意味着 DLM(Data Lifecycle Management) 需要一个快照仓库来写入数据。9.5 引入了集群级默认快照仓库,而不再要求你为每个生命周期选择一个仓库。
bash
`PUT _cluster/settings` AI写代码
json
`
1. {
2. "persistent": {
3. "repositories.default_repository": "my-snapshot-repo"
4. }
5. }
`AI写代码
DLM 会将这个仓库用于集群中每个冻结层索引。在 Elastic Cloud Hosted(ECH)上,默认仓库会预先设置为 found-snapshots,因此现有集群开箱即用。如果你希望将冻结数据保存在自己控制的存储桶中,也可以将其修改为你自己管理的仓库。这对于希望使用对象版本控制、将生命周期备份到 Glacier,或者其他需要存储桶级访问权限的场景很有用。
无论你在 Kibana 中哪里设置 frozen_after,界面都会直接显示当前默认仓库,并提供修改位置的链接,因此你可以清楚地看到冻结数据将写入哪里。
如果集群没有配置默认仓库,你仍然可以使用 frozen_after 创建生命周期。API 会接受该配置,但返回警告:
markdown
`
1. {
2. "acknowledged": true,
3. "warnings": [
4. {
5. "message": "No default snapshot repository has been configured. Data will not be moved to the frozen tier until a default snapshot repository is configured."
6. }
7. ]
8. }
`AI写代码
在配置默认仓库并且仓库可用之前,数据会一直保留在热层。如果集群没有有效的 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