[
https://issues.apache.org/jira/browse/CASSANDRA-9179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14494370#comment-14494370
]
Jonathan Ellis commented on CASSANDRA-9179:
-------------------------------------------
bq. This also applies to the case where a schema has been changed but then
reverted
As soon as you say DROP TABLE you're telling Cassandra "I don't want this data
anymore." Recreating it with the same schema is simply not the same as not
having dropped it in the first place.
bq. Is it possible to manually change the ID of an existing table as a
workaround, or will that cause all sorts of Bad Things?
Maybe. Restarting C* might be necessary. It definitely assumes that IDs don't
change right now.
> Unable to "point in time" restore if table/cf has been recreated
> ----------------------------------------------------------------
>
> Key: CASSANDRA-9179
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9179
> Project: Cassandra
> Issue Type: Bug
> Reporter: Jon Moses
> Assignee: Branimir Lambov
>
> 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
(v6.3.4#6332)
