[ https://issues.apache.org/jira/browse/CASSANDRA-9669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15101593#comment-15101593 ]
Sylvain Lebresne commented on CASSANDRA-9669: --------------------------------------------- That clause doesn't prevent all sstable version changes. It's ok to do a "minor" sstable version bump by adding new fields at the end of the sstable metadata since older version will just ignore it. From a quick glance to the patch, it does seem to change the metadata in a way that is not backward compatible, but it looks trivial to change it so that it is. This is listed at the end of the compatibility document btw. > 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)