[
https://issues.apache.org/jira/browse/CASSANDRA-10112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700986#comment-14700986
]
Benedict commented on CASSANDRA-10112:
--------------------------------------
I think in the event of failure we should just print out all of the information
we have, and let the operator decide what to do. Listing the transaction logs
that are corrupted, along with a brief summary of their contents. It would be
nice to print one row for each row in the problematic transaction log,
informing the user of the file that's referenced, if it exists, and if the row
was corroborated by checksum. We could also output a brief explanation of the
transaction logs themselves, or reference the NEWS.txt. I think that should
give them all the information they need to make a rational decision.
> Apply disk_failure_policy to transaction logs
> ---------------------------------------------
>
> Key: CASSANDRA-10112
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10112
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Stefania
> Assignee: Stefania
>
> Transaction logs were introduced by CASSANDRA-7066 and are read during
> start-up. In case of file system errors, such as disk corruption, we
> currently log a panic error and leave the sstable files and transaction logs
> as they are; this is to avoid rolling back a transaction (i.e. deleting
> files) by mistake.
> We should instead look at the {{disk_failure_policy}} and refuse to start
> unless the failure policy is {{ignore}}.
> We should also consider stashing files that cannot be read during startup,
> either transaction logs or sstables, by moving them to a dedicated
> sub-folder.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
