You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem?
When rolling over old style date based indices there is really no option to manage date based indices in a manner that scales.
The min_index_age can't "catch all" as a monthly index would require that you wait 32d days, and a daily index 1d.
What solution would you like?
Add a not_updated_since transition condition to Index State Management / ISM and update the documentation accordingly.
The goal is that the transition will not occur unless the index has been idle for the defined time.
What alternatives have you considered?
One must configure date based indices to have a known suffix (or prefix) and set up policies for each and every variety.
Do you have any additional context?
N/A
The text was updated successfully, but these errors were encountered:
What is the use case of the not_updated_since transition condition you proposed?
The use case I am thinking: ISM rollover index-1 and then index-1 will be read-only. And after some time, you want ISM to transition?
This use case should be covered by this min_rollover_age transition condition #215
As mentioned early in my issue this is regarding date based indices logstash-app-2022.05.monthly i.e. - and doing force merge / deletion based on the index age.
The purpose of my suggestion was to implement an action only when the index is no longer written to - without having to handle daily and monthly indices differently.
if <not-written-to-for-a-day; then force-merge if <not-written-to-for-90-days; then delete
I see thanks. Then we would need a good way to define what is not-written-to. I think sequence number would be a good way to keep track of that. @downsrob , @dbbaughe , @thalurur please share your thoughts
I believe that to check if an index has been updated (documents added, modified, or deleted), we need to track maximum sequence number per shard and total number of documents for the index. If only document creates and updates need to be tracked then we only need max sequence number per shard.
Is your feature request related to a problem?
When rolling over old style date based indices there is really no option to manage date based indices in a manner that scales.
The
min_index_age
can't "catch all" as amonthly
index would require that you wait32d
days, and a daily index1d
.What solution would you like?
Add a
not_updated_since
transition condition to Index State Management / ISM and update the documentation accordingly.The goal is that the transition will not occur unless the index has been idle for the defined time.
What alternatives have you considered?
One must configure date based indices to have a known suffix (or prefix) and set up policies for each and every variety.
Do you have any additional context?
N/A
The text was updated successfully, but these errors were encountered: