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
{{ message }}
This repository has been archived by the owner on Aug 23, 2023. It is now read-only.
Is your feature request related to a problem? Please describe.
Currently delByQuery deletes series from both memory and cassandra. It would be nice to support an option to archive similar to mt-index-prune.
Describe the solution you'd like
An additional option to delByQuery named method (or similar) that can currently have the options delete or archive. Perhaps memory to delete from the memory index only (though I could see this causing issues).
Additional context
Combined with #1976 this would allow us to more safely "delete"/"prune" data from Metrictank.
The text was updated successfully, but these errors were encountered:
interesting idea.
currently, mt-index-prune (or more generally moving metricDefs to the archive table) is an optimization, something that by itself shouldn't have user visible impact, as it should only move metricDefs that have already been expired and thus are not in the in memory index anyway.
so your idea is basically to explicitly move unexpired entries from the main table (and the in memory idx) to the archive table. This goes beyond what this mechanic was designed for, but i see how it can make sense.
It sounds like something that can be done without breaking anything.
Is your feature request related to a problem? Please describe.
Currently delByQuery deletes series from both memory and cassandra. It would be nice to support an option to archive similar to
mt-index-prune
.Describe the solution you'd like
An additional option to
delByQuery
namedmethod
(or similar) that can currently have the optionsdelete
orarchive
. Perhapsmemory
to delete from the memory index only (though I could see this causing issues).Additional context
Combined with #1976 this would allow us to more safely "delete"/"prune" data from Metrictank.
The text was updated successfully, but these errors were encountered: