作者来自 Elastic Jon Avezbaki在 Elasticsearch 9.5 中数据流生命周期中的 frozen_after 会自动将索引迁移到对象存储上的可搜索快照中同时保持索引可查询并与降采样和保留策略协同工作。在 Elasticsearch 9.5 中数据流生命周期可以将后备索引移动到冻结层作为对象存储上的可搜索快照而无需配置 ILM 策略。在几行 JSON 中将frozen_after添加到data_retention和可选的降采样旁边或者在 Kibana 中进行设置。该功能已在 9.5 中正式发布。如何在数据流生命周期中配置 frozen_afterfrozen_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 会拒绝。冻结层数据存储在哪里默认快照仓库冻结层数据以部分挂载的可搜索快照形式保存这意味着 DLMData Lifecycle Management 需要一个快照仓库来写入数据。9.5 引入了集群级默认快照仓库而不再要求你为每个生命周期选择一个仓库。PUT _cluster/settings{ persistent: { repositories.default_repository: my-snapshot-repo } }DLM 会将这个仓库用于集群中每个冻结层索引。在 Elastic Cloud HostedECH上默认仓库会预先设置为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_afterKibana 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已经配置好。对于声明式工作流将相同的配置写入索引模板这样新创建的数据流就会自动采用该生命周期。了解更多数据流生命周期冻结层概览可搜索快照管理 Streams 的数据保留本文中所描述的任何功能或特性的发布时间和推出时间均由 Elastic 自行决定。任何当前尚未提供的功能或特性可能无法按时交付也可能根本不会交付。原文Frozen tier without ILM: data stream lifecycle in Elasticsearch | Elasticsearch Labs