cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus Eriksson (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9179) Unable to "point in time" restore if table/cf has been recreated
Date Mon, 14 Dec 2015 11:54:46 GMT


Marcus Eriksson commented on CASSANDRA-9179:

bq. I did not want to put it in the TableParams as they can be changed using CFMetaData.params.
If it's not a TableParams value I didn't think it's a good idea to put the identifier (and
validation etc.) there.
ok, +1

I'll commit once the 2.1 dtests pass

> Unable to "point in time" restore if table/cf has been recreated
> ----------------------------------------------------------------
>                 Key: CASSANDRA-9179
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: CQL, Distributed Metadata
>            Reporter: Jon Moses
>            Assignee: Branimir Lambov
>              Labels: doc-impacting
> With Cassandra 2.1, and the addition of the CF UUID, the ability to do a "point in time"
restore by restoring a snapshot and replaying commitlogs is lost if the table has been dropped
and recreated.
> When the table is recreated, the cf_id changes, and the commitlog replay mechanism skips
the desired mutations as the cf_id no longer matches what's present in the schema.
> There should exist a way to inform the replay that you want the mutations replayed even
if the cf_id doesn't match.

This message was sent by Atlassian JIRA

View raw message