[ https://issues.apache.org/jira/browse/CASSANDRA-19617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847118#comment-17847118 ]
Jeremiah Jordan commented on CASSANDRA-19617: --------------------------------------------- Where are we at with this? It is the final ticket blocking releases at the moment. > Paxos may re-distribute stale commits that predate a collectable tombstone > -------------------------------------------------------------------------- > > Key: CASSANDRA-19617 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19617 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Coordination > Reporter: Benedict Elliott Smith > Assignee: Benedict Elliott Smith > Priority: Normal > Fix For: 4.1.x, 5.0-rc, 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > Note: this bug only affects {{paxos_state_purging: {gc_grace, repaired}}}, > i.e. those introduced alongside Paxos v2. > There are two problems: > 1) Purging is applied only on compaction, not on load, which can lead to very > old commits being resurfaced in certain circumstances > 2) PaxosPrepare does not filter commits based on paxos repair low bound > This permits surprising situations to arise, where some replicas purge a > stale commit _and all newer commits_, but due to compaction peculiarities > some other replica may purge only the newer commits, leaving a stale commit > in some compaction "purgatory"\[1] to be returned to reads indefinitely. > So long as there are no newer commits, the paxos coordinator will see this > commit is not universally known and redistribute it - no matter how old it > is. This can permit an insert to be reapplied after GC grace has elapsed and > the tombstone has been collected. > For proposals this is not a problem, as we correctly filter proposals based > on the last paxos repair time. This also does not affect clusters with the > legacy (and default) paxos state purging using TTL. Problem (1) only applies > also to the new {{gc_grace}} compatibility mode for purging. > \[1] Compaction purgatory can arise for instance because paxos purging allows > whole sstables to be erased quite effectively, and if this is able to > ordinarily prevent sstables being promoted to L1, then if for some abnormal > reason sstables reach L1 (e.g. repairs being disabled for some time), those > that collect may remain uncompacted for an extended period without purging > being applied. -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org