cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5704) Truncate flushes to disk again in 1.2, even with durable_writes=false
Date Wed, 26 Jun 2013 14:30:21 GMT

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

Jonathan Ellis commented on CASSANDRA-5704:
-------------------------------------------

Hmm.  I'm not sure I'm convinced that we should not save the truncation record when durable
writes are disabled.  Durable writes means "I'm okay if you lose the data I'm about to write
in case of power failure," but not flushing the truncate means "Data that was supposed to
be gone, could reappear" which feels semantically different to me.

WDYT [~brandon.williams] [~tjake]?

(I note that for production use, CASSANDRA-4906 made the biggest difference since now we only
need to flush the table being truncated instead of everyone.)
                
> Truncate flushes to disk again in 1.2, even with durable_writes=false
> ---------------------------------------------------------------------
>
>                 Key: CASSANDRA-5704
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5704
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.2.5
>            Reporter: Christian Spriegel
>            Assignee: Christian Spriegel
>            Priority: Minor
>             Fix For: 1.2.7
>
>         Attachments: CASSANDRA_5704_V1_1_2.patch, CASSANDRA_5704_V1_trunk.patch
>
>
> I just upgraded my dev-environment to C* 1.2. Unfortunetaly 1.2 makes my JUnit tests
slow again, due to a blocking-flush in saveTruncationRecord().
> With Cassandra 1.1 truncate was very fast due to: CASSANDRA-4153
> My proposal is to make saveTruncationRecord() only flush when durableWrites are enabled.
> My assumption is that if somebody turn off durable writes then he does not mind if truncate
is not guaranteed to be durable either.
> I successfully tested the following patch with my testsuite. Its as fast as it was with
1.1 (maybe even faster!):
> {code}
> @@ -186,5 +186,8 @@ public class SystemTable
>          String req = "UPDATE system.%s SET truncated_at = truncated_at + %s WHERE key
= '%s'";
>          processInternal(String.format(req, LOCAL_CF, truncationAsMapEntry(cfs, truncatedAt,
position), LOCAL_KEY));
> -        forceBlockingFlush(LOCAL_CF);
> +        
> +        KSMetaData ksm = Schema.instance.getKSMetaData(cfs.table.name);
> +        if (ksm.durableWrites) // flush only when durable_writes are enabled
> +            forceBlockingFlush(LOCAL_CF);
>      }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message