Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 19 Nov 2015 16:24:11 +0000 (UTC)
From: "Aleksey Yeschenko (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12820551.1428937707000.124123.1447950251316@Atlassian.JIRA>
In-Reply-To: <JIRA.12820551.1428937707000@Atlassian.JIRA>
References: <JIRA.12820551.1428937707000@Atlassian.JIRA>
 <JIRA.12820551.1428937707578@arcas>
Subject: [jira] [Updated] (CASSANDRA-9179) Unable to "point in time" restore
 if table/cf has been recreated
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CASSANDRA-9179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aleksey Yeschenko updated CASSANDRA-9179:
-----------------------------------------
    Priority: Major  (was: Minor)

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