[jira] [Updated] (CASSANDRA-6503) sstables from stalled repair sessions become live after a reboot and can resurrect deleted data

["Jason Brown (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-6503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Brown updated CASSANDRA-6503:
-----------------------------------

    Attachment: 6503_c1.2-v1.patch

Attached patch, 6503_c1.2-v1, defers the release of the sstables to the CFS until the session is complete. Note: that patch is only for 1.2.

For c* 2.0, I'd like [~yukim]'s advice. I have a WIP here: https://github.com/jasobrown/cassandra/tree/6503_c2.0. The problem I'm running into is that FileMessage.sstable is of type SSTableReader, which we need on the sender side, but on the receiver side we want SSTableWriter (if we are going to defer the release of the sstables. For hacking things up sake, I've just changed FileMessage.sstable to a plain SSTable and let the users do the casting - which is only in two places, one of which is the FileMessage.Serializer.serailize() method. Not very extensive, but perhaps a bit sloppy.

Yuki, do you think it's worthwhile to split up the FileMessage object into two classes like OutFileMessage (which has a SSTR) and InFileMessage (which has SSTW)? 

> sstables from stalled repair sessions become live after a reboot and can resurrect deleted data
> -----------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-6503
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6503
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Jeremiah Jordan
>            Assignee: Yuki Morishita
>            Priority: Minor
>             Fix For: 1.2.14, 2.0.5
>
>         Attachments: 6503_c1.2-v1.patch
>
>
> The sstables streamed in during a repair session don't become active until the session finishes.  If something causes the repair session to hang for some reason, those sstables will hang around until the next reboot, and become active then.  If you don't reboot for 3 months, this can cause data to resurrect, as GC grace has expired, so tombstones for the data in those sstables may have already been collected.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)