[
https://issues.apache.org/jira/browse/CASSANDRA-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016133#comment-13016133
]
Jonathan Ellis commented on CASSANDRA-2419:
-------------------------------------------
Hmm, I think we need both the CL header and this information, since this flush
footer would only give us when we flushed which is not the same as "do I need
to replay."
For instance: if there is no flush marker for a commitlog segment in any
existing sstable, that does not necessarily mean no data is in the commitlog
for that CF.
So replay position would be max(dirty at from CL header, flushed at from
sstable footers).
(You would need to allow multiple flush contexts in a single sstable footer, to
preserve them during compaction.)
> 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
