[
https://issues.apache.org/jira/browse/CASSANDRA-21221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18066355#comment-18066355
]
Josh McKenzie commented on CASSANDRA-21221:
-------------------------------------------
Maybe we should enable that by default in {{{}conf/cassandra_latest.yaml{}}}.
Seems like the kind of thing that should be enabled by default since we cycle
through CommitLogs pretty quickly (way more quickly than every
{{{}gc_grace{}}}, even in slow clusters), so the "best worst option" on
something flexible like this would be the conservative approach.
> Refuse to start Cassandra if local data is dangerously stale
> ------------------------------------------------------------
>
> Key: CASSANDRA-21221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21221
> Project: Apache Cassandra
> Issue Type: Improvement
> Reporter: Elliott Sims
> Priority: Normal
>
> So I'm not sure the best way to define/implement this, but I've implemented
> it as an awkward systemd pre-check script. It occurred to me that it'd make
> running Cassandra easier/safer if a cleaner version of this were built in.
> Essentially, if an old (usually replaced or otherwise retired) node comes
> back online for some reason after being offline longer than gc_grace_period
> it can cause data inconsistency. My pre-check script just does a static "if
> commitlogs exist and the file date is more than 8 days old, bail before
> starting Cassandra", but something built into Cassandra could be smarter in
> addition to being safer and easier. Something like "if the newest commitlog
> write on the instance is older than gc_grace_seconds for any table without
> only_purge_repaired_tombstones set, exit rather than joining the cluster"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
