You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jonathan Ellis (JIRA)" <ji...@apache.org> on 2009/05/28 21:47:45 UTC

[jira] Updated: (CASSANDRA-204) Replayed log data is not flushed before logs are wiped

     [ https://issues.apache.org/jira/browse/CASSANDRA-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonathan Ellis updated CASSANDRA-204:
-------------------------------------

    Attachment: 204.patch

Sorry, cleanup got mixed in with the bugfix here.

The fix is, call MT.put instead of putOnRecover.  pOR() didn't set dirty, so it was basically a broken put().  Removed it.  (Client code goes through apply(), which schedules put() on the executor.  So recover calling put directly is exactly what we want.)

The rest is removing comments that weren't actually accurate, and making startup messages more signal than noise (which is what made the problem clear).

> Replayed log data is not flushed before logs are wiped
> ------------------------------------------------------
>
>                 Key: CASSANDRA-204
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-204
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Jonathan Ellis
>            Assignee: Jonathan Ellis
>            Priority: Critical
>         Attachments: 204.patch
>
>
> The memtable created by replaying commit logs on startup is supposed to be flushed as a SSTable before the commitlog is removed, but this is not happening.  So you can lose data by doing the following:
> 1. insert data
> 2. restart cassandra (using kill, to force replay)
> 3. restart cassandra again

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