[jira] [Issue Comment Edited] (CASSANDRA-2419) Risk of counter over-count when recovering commit log

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

    [ 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