cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mathijs Vogelzang (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-6478) Importing sstables through sstableloader tombstoned data
Date Thu, 12 Dec 2013 10:57:07 GMT


Mathijs Vogelzang updated CASSANDRA-6478:

    Since Version: 2.0.3
    Fix Version/s: 2.0.3

> Importing sstables through sstableloader tombstoned data
> --------------------------------------------------------
>                 Key: CASSANDRA-6478
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Tools
>         Environment: Cassandra 2.0.3
>            Reporter: Mathijs Vogelzang
>             Fix For: 2.0.3
> 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
> This happened again exactly the same way when we cleared the new cluster and ran sstableloader
> 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

This message was sent by Atlassian JIRA

View raw message