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

Benedict edited comment on CASSANDRA-9669 at 9/10/15 10:41 AM:
---------------------------------------------------------------

There was a consensus that it was too late in 2.0's lifecycle to fix this 
there, however the patch is available for anyone that wants to apply it.

I've merged/rebased with 2.1 
[here|https://github.com/belliottsmith/cassandra/tree/9669-2.1], which 
necessarily changes it not insignificantly. It's ready for another round of 
review (although CI is screwy right now, so hard to say with certainty it 
hasn't introduced any regressions).



was (Author: benedict):
There was a consensus that it was too late in 2.0's lifecycle to fix this 
there, however the patch is available for anyone that wants to apply it.

I've merged/rebased with 2.1 
[here|https://github.com/belliottsmith/cassandra/tree/9669-2.1], which 
necessarily changes it not insignificantly. It's ready for another round of 
review.


> 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: Core
>            Reporter: Benedict
>            Assignee: Benedict
>            Priority: Critical
>              Labels: correctness
>             Fix For: 3.x, 2.1.x, 2.2.x, 3.0.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)

Reply via email to