[jira] [Commented] (CASSANDRA-19617) Paxos may re-distribute stale commits that predate a collectable tombstone

["C. Scott Andreas (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-19617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17843287#comment-17843287 ] 

C. Scott Andreas commented on CASSANDRA-19617:
----------------------------------------------

Affects: 4.1.x, 5.0.x, trunk.

> 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
>
>
> 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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org