[
https://issues.apache.org/jira/browse/CASSANDRA-6503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-6503:
--------------------------------------
Attachment: 6503_2.0-v3.diff
bq. In the first patch, I chose to write the lockfile out to the commitlog
directory.
How about using SSTable directory itself? You can access it using Directories
object so it is easy to perform delete if we do it inside
CFS.scrubDataDirectories. Attaching patch for this.
Other than that, it seems good.
bq. ...I would still like to do something for 1.2 but I do not think we need
to be as extensive as what we're doing for 2.0+. Perhaps leave out the lockfile
and the abort(), and just leave the deferring of converting SSTW to SSTR until
the end of the session...
I agree. We can commit attached 1.2 patch as well.
> 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: Jason Brown
> Priority: Minor
> Fix For: 1.2.14, 2.0.5
>
> Attachments: 6503_2.0-v2.diff, 6503_2.0-v3.diff, 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)
