Skip to content

[REQUEST]: Update frozen tier support wording for DE #1328

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
yctercero opened this issue Apr 30, 2025 · 1 comment
Open

[REQUEST]: Update frozen tier support wording for DE #1328

yctercero opened this issue Apr 30, 2025 · 1 comment
Assignees
Labels
documentation Improvements or additions to documentation needs-team Issues pending triage by the Docs Team

Comments

@yctercero
Copy link

yctercero commented Apr 30, 2025

Description

What: It was pointed out to us here that frozen can have replicas, allowing for high availability. Per the user facing ES docs that are linked below:

By default, searchable snapshot indices are mounted without replicas. Using this will result in a searchable snapshot index being mounted with a single replica for the time period specified, after which the replica will be removed. This option is only permitted on the first searchable snapshot action of a policy.

As a result, we should update our text from:

  • Replicas for mission-critical data: Your data should have replicas if it must be highly available. Since frozen tiers don't support replicas, shard unavailability can cause partial rule run failures if rules query frozen tiers. Shard unavailability may also occur during or after {stack} upgrades. If this happens, you can <<manually-run-rules,manually rerun>> rules over the affected time period once the shards are available.

to update for the fact that replicas are available:

  • Replicas for mission-critical data: Your data should have replicas if it must be highly available. Since frozen tiers don't support replicas, shard Since frozen tiers don't have replicas by default, shard unavailability can cause partial rule run failures if rules query frozen tiers without replicas. Shard unavailability may also occur during or after {stack} upgrades. If this happens, you can <<manually-run-rules,manually rerun>> rules over the affected time period once the shards are available.

When: Looks like this was merged in this past December so should be in for 8.18+

Resources

This feature was merged December 2024 - PR
This feature for frozen tier is documented - user docs.

Which documentation set does this change impact?

Elastic On-Prem and Cloud (all)

Feature differences

What release is this request related to?

8.18+

Collaboration model

The documentation team

Point of contact.

Main contact: @yctercero

Stakeholders: @approksiu @MikePaquette

@yctercero yctercero added the documentation Improvements or additions to documentation label Apr 30, 2025
@github-actions github-actions bot added the needs-team Issues pending triage by the Docs Team label Apr 30, 2025
@yctercero
Copy link
Author

Updated description to add @marshallmain 's suggestion of mentioning that shard replication is not on by default for frozen:

  • Replicas for mission-critical data: Your data should have replicas if it must be highly available. Since frozen tiers don't have replicas by default, shard unavailability can cause partial rule run failures if rules query frozen tiers without replicas. Shard unavailability may also occur during or after {stack} upgrades. If this happens, you can <<manually-run-rules,manually rerun>> rules over the affected time period once the shards are available.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation needs-team Issues pending triage by the Docs Team
Projects
None yet
Development

No branches or pull requests

2 participants