[
https://issues.apache.org/jira/browse/CASSANDRA-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006407#comment-13006407
]
Sylvain Lebresne edited comment on CASSANDRA-2279 at 3/14/11 1:45 PM:
----------------------------------------------------------------------
It's a bit of a shot in the dark since I'm not sure exactly how was produced
and how to reproduce this, but I found a place in RowIteratorFactor where we
don't handle a CF localDeletionTime correctly. Since RowIterator is used for
repair and for sstable2json, it sounds like a promising candidate for this (and
it's a legit problem even if not the one at hand here).
Patch is against 0.7.
was (Author: slebresne):
It's a bit of a shot in the dark since I'm not sure exactly how was
produced and how to reproduce this, but I found a place in RowIteratorFactor
where we don't handle a CF localDeletionTime correctly. Since RowIterator is
used for repair and for sstable2json, it sounds like a promising candidate for
this (and it's a legit problem even if not the one at hand here).
> Tombstones not collected post-repair
> ------------------------------------
>
> Key: CASSANDRA-2279
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2279
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Affects Versions: 0.6
> Reporter: Joaquin Casares
> Assignee: Sylvain Lebresne
> Priority: Minor
> Fix For: 0.6.13, 0.7.4
>
> Attachments: 0001-Handle-localDeletionTime-in-RowIteratorFactory.patch
>
>
> The keys would only show up in sstables2json and look like this:
> (root@aps4):/opt/cassandra/storage/queue/data/Panama Wed Feb 23 07:24:34am
> ===> /opt/cassandra/bin/sstable2json Queue-2527-Data.db -k
> waq:publicMessageIndexingWorkArea:PUM8a65ce95-9d35-4941-928c-dd5965e8b29b
> 2011-02-23 07:24:43,710 INFO [org.apache.cassandra.config.DatabaseDescriptor]
> - DiskAccessMode 'auto' determined to be mmap, indexAccessMode is mmap
> 2011-02-23 07:24:43,972 INFO [org.apache.cassandra.io.SSTableReader] -
> Opening /opt/cassandra/storage/queue/data/Panama/Queue-2527-Data.db
> {
> "waq:publicMessageIndexingWorkArea:PUM8a65ce95-9d35-4941-928c-dd5965e8b29b":
> []
> }
> (root@aps4):/opt/cassandra/storage/queue/data/Panama Wed Feb 23 07:24:44am
> ===>
> The steps that I took to reproduce it were:
> Create a keyspace, column family, and a key
> Delete the key on Node 1 using the cli (del cf['key'];)
> Flush
> Repair on a cluster with more than 1 node
> Wait GCSeconds
> Compact
> And the empty row would appear on Node 2
> However, when I was able to get rid of the empty rows, I was following these
> steps on a single machine:
> Create a keyspace, column family, and a key
> Delete the key
> Flush
> Sample write (writing to some temporary key)
> Deleting the attribute to that temporary key (not the entire key)
> Flush
> Compact
> or these steps:
> Create a keyspace, column family, and a key
> Delete the key
> Flush
> Wait GCseconds
> Compact
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
