You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jonathan Ellis (JIRA)" <ji...@apache.org> on 2011/02/22 00:44:38 UTC
[jira] Updated: (CASSANDRA-2211) Cleanup can create sstables whose
contents do not match their advertised version
[ https://issues.apache.org/jira/browse/CASSANDRA-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-2211:
--------------------------------------
Attachment: 2211.txt
> Cleanup can create sstables whose contents do not match their advertised version
> --------------------------------------------------------------------------------
>
> Key: CASSANDRA-2211
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2211
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.7.1
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 0.7.3
>
> Attachments: 2211.txt
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> Since cleanup switched to per-sstable operation (CASSANDRA-1916), the main loop looks like this:
> {code}
> if (Range.isTokenInRanges(row.getKey().token, ranges))
> {
> writer = maybeCreateWriter(sstable, compactionFileLocation, expectedBloomFilterSize, writer);
> writer.append(new EchoedRow(row));
> totalkeysWritten++;
> }
> else
> {
> while (row.hasNext())
> {
> IColumn column = row.next();
> if (indexedColumns.contains(column.name()))
> Table.cleanupIndexEntry(cfs, row.getKey().key, column);
> }
> }
> {code}
> ... that is, rows that haven't changed we copy to the new sstable without deserializing, with EchoedRow. But, the new sstable is created with CURRENT_VERSION which may not be what the old data consisted of.
> (This could cause symptoms similar to CASSANDRA-2195 but I do not think it is the cause of that bug; IIRC the cluster in question there was not upgraded from an older Cassandra.)
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira