[
https://issues.apache.org/jira/browse/CASSANDRA-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705098#action_12705098
]
Jonathan Ellis commented on CASSANDRA-78:
-----------------------------------------
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
> 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.
