可搜索快照
编辑可搜索快照
编辑允许的阶段:热,冷,冻结。
对配置存储库中受管索引进行快照,并将其作为可搜索快照挂载。如果索引是数据流的一部分,则挂载的索引将替换数据流中的原始索引。
searchable_snapshot
操作需要数据层。此操作使用index.routing.allocation.include._tier_preference
设置将索引直接挂载到阶段对应的数据层。在冻结阶段,此操作会将以 partial-
为前缀的部分挂载索引 挂载到冻结层。在其他阶段,此操作会将以 restored-
为前缀的完全挂载索引 挂载到对应的数据层。
在冻结层中,此操作将忽略设置index.routing.allocation.total_shards_per_node
(如果原始索引中存在此设置),以考虑冻结层和其他层之间节点数量的差异。要为可搜索快照设置index.routing.allocation.total_shards_per_node
,请在 ILM 策略中冻结阶段的 searchable_snapshot
操作中设置 total_shards_per_node
选项。
不要同时在热阶段和冷阶段包含 searchable_snapshot
操作。这可能导致索引无法在冷阶段自动迁移到冷层。
如果在热阶段使用 searchable_snapshot
操作,则后续阶段不能包含 shrink
或 forcemerge
操作。
此操作不能在数据流的写入索引上执行。尝试这样做将会失败。要将索引转换为可搜索快照,请首先手动滚动数据流。这将创建一个新的写入索引。由于该索引不再是数据流的写入索引,因此该操作可以将其转换为可搜索快照。使用在热阶段利用滚动操作的策略将避免这种情况,并且无需为将来的受管索引进行手动滚动。
挂载和重新定位可搜索快照索引的分片涉及从快照存储库复制分片内容。这可能会产生与常规索引之间节点之间复制不同的成本。这些成本通常较低,但在某些环境中可能较高。有关更多详细信息,请参阅使用可搜索快照降低成本。
默认情况下,此快照将由删除阶段中的删除操作删除。要保留快照,请在删除操作中将 delete_searchable_snapshot
设置为 false
。此快照保留依赖于索引生命周期管理 (ILM) 策略,不受快照生命周期管理 (SLM) 策略的影响。
选项
编辑在 forcemerge
期间正在重新定位的分片将不会合并。searchable_snapshot
操作即使并非所有分片都已强制合并,也会继续执行。
此强制合并发生在索引所在的阶段之前searchable_snapshot
操作。例如,如果在hot
阶段使用searchable_snapshot
操作,则会在热节点上执行强制合并。如果在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" } } } } } }