[
https://issues.apache.org/jira/browse/CASSANDRA-9669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15101477#comment-15101477
]
Sylvain Lebresne commented on CASSANDRA-9669:
---------------------------------------------
bq. According to https://wiki.apache.org/cassandra/CompatibilityGuarantees this
may have to be delayed until 4.0
Can you clarify which rule would be broken by this patch? If that's the
downgrading one due a change to the commit log format, then that's a good point
but I think I'd be personally fine amending that rule slightly to say that you
can downgrade but you have to drain before doing so. The other option being to
proceed in 2 steps: have an intermediate version that is able to read both the
old and new format of the commit log, but still write the old one, and
switching to the new one in the following version. Or of course to wait for 4.0.
> If sstable flushes complete out of order, on restart we can fail to replay
> necessary commit log records
> -------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-9669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9669
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
> Reporter: Benedict
> Assignee: Benedict
> Priority: Critical
> Labels: correctness
> Fix For: 2.2.x, 3.0.x, 3.x
>
>
> While {{postFlushExecutor}} ensures it never expires CL entries out-of-order,
> on restart we simply take the maximum replay position of any sstable on disk,
> and ignore anything prior.
> It is quite possible for there to be two flushes triggered for a given table,
> and for the second to finish first by virtue of containing a much smaller
> quantity of live data (or perhaps the disk is just under less pressure). If
> we crash before the first sstable has been written, then on restart the data
> it would have represented will disappear, since we will not replay the CL
> records.
> This looks to be a bug present since time immemorial, and also seems pretty
> serious.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
