[
https://issues.apache.org/jira/browse/CASSANDRA-10421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14939671#comment-14939671
]
Benedict commented on CASSANDRA-10421:
--------------------------------------
Well, this messes things up, no doubt about it. Since we can then have the
commit fail writing to one txn log, after succeeding writing to another, and
then we will abort some - and the txn logs will end up in an inconsistent
state. Our definition of "committed" being based on the presence of the
"commit" flag is bust.
I suspect our best/safest/most correct option is to duplicate wholesale the txn
log onto all of our affected data drives. This is ugly conceptually, but it
means on replay we just check they're all the same (with the possibility of one
extra record in some files versus others). We would then always take the txn
log with the most information as the one to consume, but if they are
inconsistent perform our most paranoid checks. This way, once we have committed
to one txn log, we can semantically-consistently ignore a failure to commit to
another, and the transaction will still be considered committed. However we
will still detect a corruption caused by a problematic disk, and in that
situation leave all files intact.
(NB: I suspect streaming can also be modelled as multiple transactions, safely)
> Potential issue with LogTransaction as it only checks in a single directory
> for files
> -------------------------------------------------------------------------------------
>
> Key: CASSANDRA-10421
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10421
> Project: Cassandra
> Issue Type: Bug
> Reporter: Marcus Eriksson
> Assignee: Stefania
> Priority: Blocker
> Fix For: 3.0.0 rc2
>
>
> When creating a new LogTransaction we try to create the new logfile in the
> same directory as the one we are writing to, but as we use
> {{[directories.getDirectoryForNewSSTables()|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/lifecycle/LogTransaction.java#L125]}}
> this might end up in "any" of the configured data directories. If it does,
> we will not be able to clean up leftovers as we check for files in the same
> directory as the logfile was created:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/lifecycle/LogRecord.java#L163
> cc [~Stefania]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
