cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-2872) While dropping and recreating an index, incremental snapshotting can hang
Date Tue, 12 Jul 2011 23:44:59 GMT

    [ 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

        

Mime
View raw message