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

Stefania commented on CASSANDRA-13294:
--------------------------------------

I think we still have a problem with the proposed patch because for legacy 
files it can also get the wrong [record 
files|https://github.com/stef1927/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/lifecycle/LogFile.java#L368],
 which would cause an incorrect classification of files in a folder, for 
example by considering unrelated sstable files as temporary.

Therefore I've added the descriptor separator to the absolute path. However, we 
must be careful not to write it to the txn files, to make sure that we can 
still upgrade from 3.0.x versions onward. In case of a non clean shutdown, 
there could be some txn files from the old version to be processed on startup 
by the upgraded version, I think it's easier not to write the additional 
separator rather than handling parsing and checksum differently. This way we 
can simply avoid committing this patch to trunk and carry on without the 
additional separator since it is not required for 3.0+ files.

Revised patch is here,  what do you think [~krummas]?

||3.0||3.11||
|[patch|https://github.com/stef1927/cassandra/tree/13294-3.0]|[patch|https://github.com/stef1927/cassandra/tree/13294-3.11]|
|[testall|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-13294-3.0-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-13294-3.11-testall/]|
|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-13294-3.0-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-13294-3.11-dtest/]|


> Possible data loss on upgrade 2.1 - 3.0
> ---------------------------------------
>
>                 Key: CASSANDRA-13294
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13294
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Marcus Eriksson
>            Assignee: Marcus Eriksson
>            Priority: Blocker
>             Fix For: 3.0.x, 3.11.x
>
>
> After finishing a compaction we delete the compacted away files. This is done 
> [here|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/lifecycle/LogFile.java#L328-L337]
>  which uses 
> [this|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/lifecycle/LogRecord.java#L265-L271]
>  to get the files - we get all files starting with {{absoluteFilePath}}. 
> Absolute file path is generated 
> [here|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/Descriptor.java#L142-L153].
>  For 3.0 version files the filename looks like this: 
> {{/blabla/keyspace1/standard1-bdb031c0ff7b11e6940fdd0479dd8912/mc-1332-big}} 
> but for 2.1 version files, they look like this: 
> {{/blabla/keyspace1/standard1-bdb031c0ff7b11e6940fdd0479dd8912/keyspace1-standard1-ka-2}}.
> The problem is then that if we were to finish a compaction including the 
> legacy file, we would actually delete all legacy files having a generation 
> starting with '2'



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to