bdeggleston commented on code in PR #3289:
URL: https://github.com/apache/cassandra/pull/3289#discussion_r1589783789
##########
src/java/org/apache/cassandra/db/SystemKeyspace.java:
##########
@@ -1373,14 +1376,38 @@ public static PaxosState.Snapshot
loadPaxosState(DecoratedKey partitionKey, Tabl
return new PaxosState.Snapshot(Ballot.none(), Ballot.none(), null,
noneCommitted);
}
+ long purgeBefore = 0;
+ long overrideTtlSeconds = 0;
+ switch (paxosStatePurging())
+ {
+ default: throw new AssertionError();
+ case legacy:
+ case gc_grace:
+ overrideTtlSeconds = metadata.params.gcGraceSeconds;
Review Comment:
I think this creates another window for state resurrection if you switch
back to repaired without having run a paxos repair in the meantime though,
since you'd no longer be applying a synthetic ttl to data that had previously
been synthetically ttl’d. The timeline would be: you have incomplete operation
A happen with purging mode `repaired`, you switch to `gc_grace` and the ttl
window elapses, you run operation B, which deletes the data that would have
been written by operation A, the ttl window for that operation passes and it’s
removed from disk, you switch back to `repaired` purging without having run a
repair in the meantime, operation A becomes visible again and is applied.
Re-reading the PaxosStatePurging docs, we only state that it’s unsafe to go
back to legacy once migrating from it, which implies that it’s ok to return to
gc_grace if you’re having repair problems and a growing paxos state table,
which I think is a useful escape hatch to keep around.
Switching back to gc_grace would also prevent the operations written while
in repaired mode from being purged properly. While we’re on the topic,
increasing gc grace when using the gc grace purge mode could also resurrect
older operations by the same general mechanism described in the JIRA.
I think we need to track a local purgeable low bound across config and
schema changes.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
