[
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)
