cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-2419) Risk of counter over-count when recovering commit log
Date Tue, 05 Apr 2011 21:31:05 GMT


Jonathan Ellis updated CASSANDRA-2419:

    Comment: was deleted

(was: to be clear: i believe if we do this we can drop CL header construct entirely.  instead,
on startup we read last N bytes of each sstable file to get start-reply-at positions -- position
for commitlog X and CF Y is max(start position) for sstables in X who were flushed during
Y's tenure.)

> Risk of counter over-count when recovering commit log
> -----------------------------------------------------
>                 Key: CASSANDRA-2419
>                 URL:
>             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:

View raw message