[
https://issues.apache.org/jira/browse/CASSANDRA-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016147#comment-13016147
]
Jonathan Ellis edited comment on CASSANDRA-2419 at 4/5/11 10:32 PM:
--------------------------------------------------------------------
I don't understand the problem. Say we have this situation:
CommitLog-1302036825548.log: [full of writes to CF Foo counters, up to position
100. header reads dirty-at 50, our last flush position]
Foo-g-45-Metadata.db: [flushed at position (1302036825548, 50)]
Foo-g-46-Metadata.db: [flushed at position (1302036825548, 100)]
We compact and get
Foo-g-47-Metadata.db: [flushed at position (1302036825548, 100)]
If we die and restart here we will correctly start reply of Foo at position 100
in this segment.
(we can combine to a single flushed-at entry in this case since they were from
the same CL segment. if they were from different segments we would keep both.)
was (Author: jbellis):
I don't understand the problem. Say we have this situation:
CommitLog-1302036825548.log: [full of writes to CF Foo counters, up to position
100. header reads dirty-at 50, our last flush position]
Foo-g-45-Metadata.db: [flushed at position (1302036825548, 50)]
Foo-g-46-Metadata.db: [flushed at position (1302036825548, 100)]
We compact and get
Foo-g-46-Metadata.db: [flushed at position (1302036825548, 100)]
If we die and restart here we will correctly start reply of Foo at position 100
in this segment.
(we can combine to a single flushed-at entry in this case since they were from
the same CL segment. if they were from different segments we would keep both.)
> 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
