[
https://issues.apache.org/jira/browse/CASSANDRA-17180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17528907#comment-17528907
]
Josh McKenzie commented on CASSANDRA-17180:
-------------------------------------------
{quote}I was thinking about enablement by default and I do not want to enable
it by default yet.
{quote}
My .02: I agree w/you re: keeping this disabled by default.
Ultimately a marker file that we use to parse if a node did anything within
gc_grace is all just a symptom of a bigger problem: us relying on gc_grace to
determine a window of time after which it's safe to delete tombstones. The
fundamental design is deeply, _deeply_ flawed. While this ticket here will
provide an optional band-aid for operators for certain use-cases to prevent
zombie data, I'd like to see us tackle this design in a more holistic fashion
that makes tickets like this unnecessary and makes purging more deterministic.
Been on my mind for a bit and I planned to bring it up on the ML after 4.1
branch and test burn down.
> Implement startup check to prevent Cassandra start to spread zombie data
> ------------------------------------------------------------------------
>
> Key: CASSANDRA-17180
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17180
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Priority: Normal
> Fix For: 4.1
>
> Time Spent: 11h 20m
> Remaining Estimate: 0h
>
> As already discussed on ML, it would be nice to have a service which would
> periodically write timestamp to a file signalling it is up / running.
> Then, on the startup, we would read this file and we would determine if there
> is some table which gc grace is behind this time and we would fail the start
> so we would prevent zombie data to be likely spread around a cluster.
> https://lists.apache.org/thread/w4w5t2hlcrvqhgdwww61hgg58qz13glw
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
