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/04 16:32:30 UTC

[jira] Issue Comment Edited: (CASSANDRA-78) Interrupted recovery requires manual intervention to fix

    [ https://issues.apache.org/jira/browse/CASSANDRA-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705097#action_12705097 ] 

Jonathan Ellis edited comment on CASSANDRA-78 at 5/4/09 7:30 AM:
-----------------------------------------------------------------

while writing these patches I checked and closeRename does fsync (via FileChannel.force).  Have not audited commitlog similarly.

Additionally, the bootstrap code uses the potentially unsafe CFS.getFileName instead of getTempFileName.  Not sure if there's actually a problem there.  (Just a note to self to come back to this after 0.3)

      was (Author: jbellis):
    while writing these patches I checked and closeRename does fsync (via FileChannel.force).  Have not audited commitlog similarly.

Additionally, the bootstrap code uses the potentially unsafe CFS.getFileName instead of getTempFileName.  Not sure if there's actually a problem there.
  
> Interrupted recovery requires manual intervention to fix
> --------------------------------------------------------
>
>                 Key: CASSANDRA-78
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-78
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Jonathan Ellis
>            Assignee: Jonathan Ellis
>            Priority: Critical
>             Fix For: 0.3
>
>         Attachments: 0001-clean-up-anticompaction-code-a-little.patch, 0002-use-getTempFileName-closeRename-to-avoid-problems.patch
>
>
> Originally reported by Alexander Staubo: "If you kill the server while it is going through its initial "row recovery" phase, you risk ending up with a database that's corrupt and will fail with "negative seek" exceptions and similar."
> Prashant replied:
> "The commit logs are only deleted after a successful recovery. You should still have teh commit log if u killed the server while recovering ? When u restart the server it should generate a new file , for compactions we name intermediate files with a .tmp and only on successful dump do we place them as usable files , this same logic is required at recovery and there is a fix coming up which will do it .
> "So with the state that u have today there will  be no data loss ass commit logs still exist but its a round about process to recover it since now u haave to delete the intermediate file and then do teh recovery again."

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