[
https://issues.apache.org/jira/browse/CASSANDRA-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13711351#comment-13711351
]
Jonathan Ellis commented on CASSANDRA-5704:
-------------------------------------------
Yes, it's a memtable write ... to the system.local table, with information
about the truncated table.
No doubt you would reply, "then let's skip the flush when durable writes are
disabled on the system keyspace," but you'll note that we've already special
cased this flush even though the memtable writes is commitlogged -- we want it
to persist immediately even with periodic commitlog mode. Truncated data
reappearing is very high on the list of Behaviors That Surprise People.
Therefore I propose the attached patch along the lines of what Jake and Brandon
suggest, that adds a {{cassandra.unsafetruncate}} property. (Normally I am not
a fan of using a 'negative' property name like 'unsafe' but I don't want to
encourage people to use it, who shouldn't, which I think we risk if we use
{{quicktruncate}} or similar.)
> 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: 5704-v2.txt, 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
