You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Sylvain Lebresne (JIRA)" <ji...@apache.org> on 2011/07/13 01:44:59 UTC

[jira] [Commented] (CASSANDRA-2872) While dropping and recreating an index, incremental snapshotting can hang

    [ https://issues.apache.org/jira/browse/CASSANDRA-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064236#comment-13064236 ] 

Sylvain Lebresne commented on CASSANDRA-2872:
---------------------------------------------

One option could be to have some kind of "index" generation that we would persist in the system tables. What I mean here is that if you create a index on say column 'birthdate' for some CF test, the index would start being called test.birthdate.1 (or just test.birthdate for compatibility sake), then if you drop it and recreate it, it would be called test.birthdate.2. That way, we would avoid the name clash during the incremental backup.

> While dropping and recreating an index, incremental snapshotting can hang 
> --------------------------------------------------------------------------
>
>                 Key: CASSANDRA-2872
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2872
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.7.4
>            Reporter: Sylvain Lebresne
>            Priority: Minor
>
> When creating a hard link (at list with JNA), link() hang if the target of the
> link already exists. In theory though, we should not hit that situation
> because we use a new directory for each manual snapshot and the generation
> number of the sstables should prevent this from hapenning with increment
> snapshot.
> However, when you drop, then recreate a secondary index, if the sstables are
> deleted after the drop and before we recreate the index, the recreated index
> sstables will start with a generation to 0. Thus, when we start backuping them
> incrementally, it will conflict with the sstables of the previously dropped
> index.
> First, we should check for the target existance because calling link() to at
> least avoid hanging. But then we must make sure that when we drop, then
> recreate an index, we will either not name the sstables the same way or the
> incremental snapshot use a different directory.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira