On Wed, Dec 11, 2013 at 6:27 AM, Mathijs Vogelzang
<math...@apptornado.com>wrote:
> When I use sstable2json on the sstable on the destination cluster, it has
> "metadata": {"deletionInfo":
> {"markedForDeleteAt":1796952039620607,"localDeletionTime":0}}, whereas
> it doesn't have that in the source sstable.
> (Yes, this is a timestamp far into the future. All our hosts are
> properly synced through ntp).
>
This seems like a bug in sstableloader, I would report it on JIRA.
> Naturally, copying the data again doesn't work to fix it, as the
> tombstone is far in the future. Apart from not having this happen at
> all, how can it be fixed?
>
Briefly, you'll want to purge that tombstone and then reload the data with
a reasonable timestamp.
Dealing with rows with data (and tombstones) in the far future is described
in detail here :
http://thelastpickle.com/blog/2011/12/15/Anatomy-of-a-Cassandra-Partition.html
=Rob
