可搜索快照
编辑可搜索快照
编辑允许的阶段：hot、cold、frozen。
在配置的存储库中获取托管索引的快照，并将其挂载为可搜索快照。如果索引是数据流的一部分，则挂载的索引将替换流中的原始索引。
searchable_snapshot 操作需要数据层。该操作使用 index.routing.allocation.include._tier_preference 设置将索引直接挂载到该阶段的相应数据层。在 frozen 阶段，该操作会将前缀为 partial- 的部分挂载索引挂载到 frozen 层。在其他阶段，该操作会将前缀为 restored- 的完全挂载索引挂载到相应的数据层。
在 frozen 层，该操作将忽略 index.routing.allocation.total_shards_per_node 设置（如果它存在于原始索引中），以解决 frozen 层和其他层之间节点数量的差异。要为可搜索快照设置 index.routing.allocation.total_shards_per_node，请在 frozen 阶段的 ILM 策略中的 searchable_snapshot 操作中设置 total_shards_per_node 选项。
不要在 hot 和 cold 阶段都包含 searchable_snapshot 操作。这会导致索引在 cold 阶段无法自动迁移到 cold 层。
如果在 hot 阶段使用 searchable_snapshot 操作，则后续阶段不能包含 shrink 或 forcemerge 操作。
此操作不能在数据流的写入索引上执行。尝试执行此操作将失败。要将索引转换为可搜索快照，首先手动滚动数据流。这将创建一个新的写入索引。由于该索引不再是流的写入索引，因此该操作可以将其转换为可搜索快照。在 hot 阶段使用 滚动 操作的策略将避免这种情况，并且不需要为将来的托管索引手动滚动。
挂载和重新定位可搜索快照索引的分片涉及从快照存储库复制分片内容。这可能会产生与常规索引在节点之间复制不同的成本。这些成本通常较低，但在某些环境中可能会较高。有关更多详细信息，请参阅使用可搜索快照降低成本。
默认情况下，此快照由 delete 阶段中的删除操作删除。要保留快照，请在删除操作中将 delete_searchable_snapshot 设置为 false。此快照保留由索引生命周期管理 (ILM) 策略运行，不受快照生命周期管理 (SLM) 策略的影响。
选项
编辑在 forcemerge 期间重新定位的分片将不会被合并。即使并非所有分片都强制合并，searchable_snapshot 操作也将继续执行。
此强制合并发生在索引进入 在 执行 searchable_snapshot 操作之前的阶段。例如，如果在 hot 阶段使用 searchable_snapshot 操作，则强制合并将在 hot 节点上执行。如果在 cold 阶段使用 searchable_snapshot 操作，则强制合并将在索引进入 cold 阶段之前所在的任何层上执行（hot 或 warm）。
-
total_shards_per_node - 可搜索快照索引的单个节点将分配的最大分片数（副本和主分片）。默认为无界。
示例
编辑resp = client.ilm.put_lifecycle(
name="my_policy",
policy={
"phases": {
"cold": {
"actions": {
"searchable_snapshot": {
"snapshot_repository": "backing_repo"
}
}
}
}
},
)
print(resp)
const response = await client.ilm.putLifecycle({
name: "my_policy",
policy: {
phases: {
cold: {
actions: {
searchable_snapshot: {
snapshot_repository: "backing_repo",
},
},
},
},
},
});
console.log(response);
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"cold": {
"actions": {
"searchable_snapshot" : {
"snapshot_repository" : "backing_repo"
}
}
}
}
}
}