[ https://issues.apache.org/jira/browse/CASSANDRA-6478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tyler Hobbs resolved CASSANDRA-6478. ------------------------------------ Resolution: Duplicate Fix Version/s: (was: 2.0.5) 2.0.4 This appears to be an exact duplicate of CASSANDRA-6527 (which is resolved), so I'm closing this ticket. > Importing sstables through sstableloader tombstoned data > -------------------------------------------------------- > > Key: CASSANDRA-6478 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6478 > Project: Cassandra > Issue Type: Bug > Components: Tools > Environment: Cassandra 2.0.3 > Reporter: Mathijs Vogelzang > Assignee: Tyler Hobbs > Fix For: 2.0.4 > > > We've tried to import sstables from a snapshot of a 1.2.10 cluster into a > running 2.0.3 cluster. When using sstableloader, for some reason we couldn't > retrieve some of the data. When investigating further, it turned out that > tombstones in the far future were created for some rows. (sstable2json > returned the correct data, but with an addition of "metadata": > {"deletionInfo": > {"markedForDeleteAt":1796952039620607,"localDeletionTime":0}} to the rows > that seemed missing). > This happened again exactly the same way when we cleared the new cluster and > ran sstableloader again. > The sstables itself seemed fine, they were working on the old cluster, > upgradesstables tells there's nothing to upgrade, and we were finally able to > move our data correctly by copying the SSTables with scp into the right > directory on the hosts of the new clusters worked fine (but naturally this > required much more disk space than when sstableloader only sends the relevant > parts). -- This message was sent by Atlassian JIRA (v6.1.5#6160)