[
https://issues.apache.org/jira/browse/CASSANDRA-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016118#comment-13016118
]
Sylvain Lebresne commented on CASSANDRA-2419:
---------------------------------------------
One solution I see to this problem would be to record along with the replay
position the time when we last updated this replay position. The during
recover, we would first look at all the sstables (for the CF) and if a sstable
is freshly flushed (which implies that we have a marker to know that a sstable
was never compacted) and have a modification time higher that the last time we
updated the replay position, then we'll just remove the sstable since we know
it will be fully replayed.
Note that to work correctly we also need a way to mark a freshly flushed
sstable as 'non compactable' during the time it takes to mark the commit log.
We would probably only do this for counter CF just to be on the safe side.
Opinions ?
> Risk of counter over-count when recovering commit log
> -----------------------------------------------------
>
> Key: CASSANDRA-2419
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2419
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.8
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Labels: counters
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> When a memtable was flush, there is a small delay before the commit log
> replay position gets updated. If the node fails during this delay, all the
> updates of this memtable will be replay during commit log recovery and will
> end-up being over-counts.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
