[
https://issues.apache.org/jira/browse/CASSANDRA-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13694036#comment-13694036
]
Christian Spriegel commented on CASSANDRA-5704:
-----------------------------------------------
{quote}"Data that was supposed to be gone, could reappear" which feels
semantically different to me.{quote}
I can understand that. My thought was that durable_writes already applies to
deletes. So I thought why not also apply that pattern to truncate?
I could live with a new "test.mode" property though (in cassandra.yaml,
right?). I would even go as far to say that this one should deactivate all
fsyncs in Cassandra :-)
Nevertheless, for practical reasons I like the idea of using the durable_writes
flag, because it allows me to use have different behaviour on my dev-laptop
for...
- ... one keyspace for my junits. These require constant truncation.
- ... my local installation of our application. Here I like a bit more data
safety, because I not want to set up my testdata all the time.
> 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
