-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Add the frozen tier node role and ILM phase #68605
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
Conversation
This commit adds the `data_frozen` node role as part of the formalization of data tiers. It also adds the `"frozen"` phase to ILM, currently allowing the same actions as the existing cold phase. The frozen phase is intended to be used for data even less frequently searched than the cold phase, and will eventually be loosely tied to data using partial searchable snapshots (as oppposed to full searchable snapshots in the cold phase). Relates to elastic#60848
|
Pinging @elastic/es-core-features (Team:Core/Features) |
...snapshots/src/main/java/org/elasticsearch/xpack/searchablesnapshots/SearchableSnapshots.java
Outdated
Show resolved
Hide resolved
jasontedor
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. The only question is around the descriptions of the querying levels in the tiers. I offered a suggestion of cold -> infrequently, frozen -> rarely, but I am open to other suggestions. The seldom, more seldom reads oddly to me.
| if ((dataRoles.size() > 1 || dataRoles.get(0).roleName().equals("data_cold") == false) || | ||
| roles.contains(DiscoveryNodeRole.MASTER_ROLE)) { | ||
| // if the node is not a dedicated cold node, use the default | ||
| if (dataRoles.stream().allMatch(dn -> dn.roleName().equals("data_cold") || dn.roleName().equals("data_frozen")) == false) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch.
jasontedor
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few nits 😇.
jasontedor
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left one more comment about a code comment, but I don't think we need another round.
We discovered that we need to separate the tier preferences for the cache index and mounted indices, so we'll take another review round here.
A full copy mount prefers cold -> warm -> hot A partial mount prefers frozen -> cold -> warm -> hot
jasontedor
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
This commit adds the `data_frozen` node role as part of the formalization of data tiers. It also adds the `"frozen"` phase to ILM, currently allowing the same actions as the existing cold phase. The frozen phase is intended to be used for data even less frequently searched than the cold phase, and will eventually be loosely tied to data using partial searchable snapshots (as oppposed to full searchable snapshots in the cold phase). Relates to elastic#60848
This commit adds the `data_frozen` node role as part of the formalization of data tiers. It also adds the `"frozen"` phase to ILM, currently allowing the same actions as the existing cold phase. The frozen phase is intended to be used for data even less frequently searched than the cold phase, and will eventually be loosely tied to data using partial searchable snapshots (as oppposed to full searchable snapshots in the cold phase). Relates to #60848
|
I think we missed one place in the docs which is docs/reference/modules/node.asciidoc. Leaving this here as a reminder for one of us to pick this up on Monday. |
This commit adds support for the recently introduced partial searchable snapshot (elastic#68509) to ILM. Searchable snapshot ILM actions may now be specified with a `storage` option, specifying either `full_copy` or `shared_cache` (similar to the "mount" API) to mount either a full or partial searchable snapshot: ```json PUT _ilm/policy/my_policy { "policy": { "phases": { "cold": { "actions": { "searchable_snapshot" : { "snapshot_repository" : "backing_repo", "storage": "shared_cache" } } } } } } ``` Internally, If more than one searchable snapshot action is specified (for example, a full searchable snapshot in the "cold" phase and a partial searchable snapshot in the "frozen" phase) ILM will re-use the existing snapshot when doing the second mount since a second snapshot is not required. Currently this is allowed for actions that use the same repository, however, multiple `searchable_snapshot` actions for the same index that use different repositories is not allowed (the ERROR state is entered). We plan to allow this in the future in subsequent work. If the `storage` option is not specified in the `searchable_snapshot` action, the mount type defaults to "shared_cache" in the frozen phase and "full_copy" in all other phases. Relates to elastic#68605
This commit adds support for the recently introduced partial searchable snapshot (elastic#68509) to ILM. Searchable snapshot ILM actions may now be specified with a `storage` option, specifying either `full_copy` or `shared_cache` (similar to the "mount" API) to mount either a full or partial searchable snapshot: ```json PUT _ilm/policy/my_policy { "policy": { "phases": { "cold": { "actions": { "searchable_snapshot" : { "snapshot_repository" : "backing_repo", "storage": "shared_cache" } } } } } } ``` Internally, If more than one searchable snapshot action is specified (for example, a full searchable snapshot in the "cold" phase and a partial searchable snapshot in the "frozen" phase) ILM will re-use the existing snapshot when doing the second mount since a second snapshot is not required. Currently this is allowed for actions that use the same repository, however, multiple `searchable_snapshot` actions for the same index that use different repositories is not allowed (the ERROR state is entered). We plan to allow this in the future in subsequent work. If the `storage` option is not specified in the `searchable_snapshot` action, the mount type defaults to "shared_cache" in the frozen phase and "full_copy" in all other phases. Relates to elastic#68605
This commit adds support for the recently introduced partial searchable snapshot (elastic#68509) to ILM. Searchable snapshot ILM actions may now be specified with a `storage` option, specifying either `full_copy` or `shared_cache` (similar to the "mount" API) to mount either a full or partial searchable snapshot: ```json PUT _ilm/policy/my_policy { "policy": { "phases": { "cold": { "actions": { "searchable_snapshot" : { "snapshot_repository" : "backing_repo", "storage": "shared_cache" } } } } } } ``` Internally, If more than one searchable snapshot action is specified (for example, a full searchable snapshot in the "cold" phase and a partial searchable snapshot in the "frozen" phase) ILM will re-use the existing snapshot when doing the second mount since a second snapshot is not required. Currently this is allowed for actions that use the same repository, however, multiple `searchable_snapshot` actions for the same index that use different repositories is not allowed (the ERROR state is entered). We plan to allow this in the future in subsequent work. If the `storage` option is not specified in the `searchable_snapshot` action, the mount type defaults to "shared_cache" in the frozen phase and "full_copy" in all other phases. Relates to elastic#68605
…68762) This commit adds support for the recently introduced partial searchable snapshot (#68509) to ILM. Searchable snapshot ILM actions may now be specified with a `storage` option, specifying either `full_copy` or `shared_cache` (similar to the "mount" API) to mount either a full or partial searchable snapshot: `json PUT _ilm/policy/my_policy { "policy": { "phases": { "cold": { "actions": { "searchable_snapshot" : { "snapshot_repository" : "backing_repo", "storage": "shared_cache" } } } } } } ` Internally, If more than one searchable snapshot action is specified (for example, a full searchable snapshot in the "cold" phase and a partial searchable snapshot in the "frozen" phase) ILM will re-use the existing snapshot when doing the second mount since a second snapshot is not required. Currently this is allowed for actions that use the same repository, however, multiple `searchable_snapshot` actions for the same index that use different repositories is not allowed (the ERROR state is entered). We plan to allow this in the future in subsequent work. If the `storage` option is not specified in the `searchable_snapshot` action, the mount type defaults to "shared_cache" in the frozen phase and "full_copy" in all other phases. Relates to #68605
This commit adds the
data_frozennode role as part of the formalization of data tiers. It alsoadds the
"frozen"phase to ILM, currently allowing the same actions as the existing cold phase.The frozen phase is intended to be used for data even less frequently searched than the cold phase,
and will eventually be loosely tied to data using partial searchable snapshots (as oppposed to full
searchable snapshots in the cold phase).
Relates to #60848