cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fabien Rousseau (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-4782) Commitlog not replayed after restart
Date Thu, 11 Oct 2012 12:09:03 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-4782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13474067#comment-13474067
] 

Fabien Rousseau commented on CASSANDRA-4782:
--------------------------------------------

Thanks for the patch. This solution is more simple and elegant than the one I proposed.

I tested it and it worked like a charm.
Nevertheless, if there are counters CF, a drain is probably necessary to avoid replaying the
full commitlog and avoid having overcounts. (I don't think it is a problem, just something
to know before the upgrade...)
                
> Commitlog not replayed after restart
> ------------------------------------
>
>                 Key: CASSANDRA-4782
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4782
>             Project: Cassandra
>          Issue Type: Bug
>    Affects Versions: 1.1.0
>            Reporter: Fabien Rousseau
>            Assignee: Jonathan Ellis
>            Priority: Critical
>             Fix For: 1.1.6
>
>         Attachments: 4782.txt
>
>
> It seems that there are two corner cases where commitlog is not replayed after a restart
:
>  - After a reboot of a server + restart of cassandra (1.1.0 to 1.1.4)
>  - After doing an upgrade from cassandra 1.1.X to cassandra 1.1.5
> This is due to the fact that the commitlog segment id should always be an  incrementing
number (see this condition : https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogReplayer.java#L247
)
> But this assertion can be broken :
> In the first case, it is generated by System.nanoTime() but it seems that System.nanoTime()
is using the boot time as the base/reference (at least on java6 & linux), thus after a
reboot, System.nanoTime() can return a lower number than before the reboot (and the javadoc
says the reference is a relative point in time...)
> In the second case, this was introduced by #4601 (which changes System.nanoTime() by
System.currentTimeMillis() thus people starting with 1.1.5 are safe)
> This could explain the following tickets : #4741 and #4481

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message