cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Schuller (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-1780) periodic + flush commitlog mode
Date Tue, 30 Nov 2010 19:38:12 GMT


Peter Schuller commented on CASSANDRA-1780:

Jonathan: My confusion was with the atomicity guarantee in this case. I do see that memtables
are okay to be flushed prior to the data being in commit log; what I was worried about was
partial or complete visibility of the data due to it being in-memory in a memtable, followed
by a crash. In this case updates would be partially or completely visible followed by disappearing
and never coming back, from the perspective of an outside observer.

I am aware isolation is not guaranteed; but I never considered that lack of isolation also
allows rolling back data that was already seen (in addition to allowing a client to see partially
applied data). It's not quite obvious to me why this is inherent in the "atomic but not isolated"
guarantee, but certainly seems like a suitable trade-off for the performance implications
of running in periodic sync mode.

> periodic + flush commitlog mode
> -------------------------------
>                 Key: CASSANDRA-1780
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Jonathan Ellis
>            Priority: Minor
>             Fix For: 0.7.0
>         Attachments: 1780.txt
> periodic-sync commitlog mode only flushes before it syncs, which means its best case
durability is very similar to its worst case.  if we had a mode that flushed but did not sync
then it would only lose data for actual power failures.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message