Searchable snapshot
editSearchable snapshot
editPhases allowed: hot, cold, frozen.
Takes a snapshot of the managed index in the configured repository and mounts it as a searchable snapshot. If the index is part of a data stream, the mounted index replaces the original index in the stream.
The searchable_snapshot action requires data tiers. The action
uses the
index.routing.allocation.include._tier_preference
setting to mount the index directly to the phase’s corresponding data tier. In
the frozen phase, the action mounts a partially mounted
index prefixed with partial- to the frozen tier. In other phases, the action mounts a
fully mounted index prefixed with restored- to the corresponding data tier.
In the frozen tier, the action will ignore the setting
index.routing.allocation.total_shards_per_node, if it was present in the original index,
to account for the difference in the number of nodes between the frozen and the other tiers.
Don’t include the searchable_snapshot action in both the hot and cold
phases. This can result in indices failing to automatically migrate to the cold
tier during the cold phase.
If the searchable_snapshot action is used in the hot phase the subsequent
phases cannot include the shrink or forcemerge actions.
This action cannot be performed on a data stream’s write index. Attempts to do so will fail. To convert the index to a searchable snapshot, first manually roll over the data stream. This creates a new write index. Because the index is no longer the stream’s write index, the action can then convert it to a searchable snapshot. Using a policy that makes use of the rollover action in the hot phase will avoid this situation and the need for a manual rollover for future managed indices.
Mounting and relocating the shards of searchable snapshot indices involves copying the shard contents from the snapshot repository. This may incur different costs from the copying between nodes that happens with regular indices. These costs are typically lower but, in some environments, may be higher. See Reduce costs with searchable snapshots for more details.
By default, this snapshot is deleted by the delete action in the delete phase.
To keep the snapshot, set delete_searchable_snapshot to false in the delete action. This
snapshot retention runs off the index lifecycle management (ILM) policies and is not effected by snapshot lifecycle management (SLM) policies.
Options
edit-
snapshot_repository - (Required, string) Repository used to store the snapshot.
-
force_merge_index -
(Optional, Boolean)
Force merges the managed index to one segment.
Defaults to
true. If the managed index was already force merged using the force merge action in a previous action thesearchable snapshotaction force merge step will be a no-op.
Shards that are relocating during a forcemerge will not be merged.
The searchable_snapshot action will continue executing even if not all shards
are force merged.
This force merging occurs in the phase that the index is in prior to the searchable_snapshot
action. For example, if using a searchable_snapshot action in the hot phase, the force merge
will be performed on the hot nodes. If using a searchable_snapshot action in the cold phase, the
force merge will be performed on whatever tier the index is prior to the cold phase (either
hot or warm).
Examples
editresp = 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"
}
}
}
}
}
}