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:37:45 UTC
[jira] Created: (CASSANDRA-204) Replayed log data is not flushed
before logs are wiped
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
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.
[jira] Updated: (CASSANDRA-204) Replayed log data is not flushed
before logs are wiped
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-204:
-------------------------------------
Fix Version/s: (was: 0.4)
0.3
> 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
> Fix For: 0.3
>
> 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.
[jira] Updated: (CASSANDRA-204) Replayed log data is not flushed
before logs are wiped
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-204:
-------------------------------------
Fix Version/s: 0.3
> 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
> Fix For: 0.3
>
> 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.
[jira] Updated: (CASSANDRA-204) Replayed log data is not flushed
before logs are wiped
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (CASSANDRA-204) Replayed log data is not flushed
before logs are wiped
Posted by "Jun Rao (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12714171#action_12714171 ]
Jun Rao commented on CASSANDRA-204:
-----------------------------------
Patch looks fine to me.
> 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
> Fix For: 0.3
>
> 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.
[jira] Resolved: (CASSANDRA-204) Replayed log data is not flushed
before logs are wiped
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis resolved CASSANDRA-204.
--------------------------------------
Resolution: Fixed
committed to 0.3 and merged to trunk
> 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
> Fix For: 0.3
>
> 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.
[jira] Commented: (CASSANDRA-204) Replayed log data is not flushed
before logs are wiped
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12714157#action_12714157 ]
Jonathan Ellis commented on CASSANDRA-204:
------------------------------------------
s/schedules on the executor/locks and checks for flush/
> 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
> Fix For: 0.3
>
> 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.