[ https://issues.apache.org/jira/browse/CASSANDRA-7582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076586#comment-14076586 ]
Benedict commented on CASSANDRA-7582: ------------------------------------- 3. We've busted something This is the main type I'm trying to catch with this behaviour. I would prefer to know earlier if 2.1 is broken instead of corrupting the user's CL in some way without realising it. We've had several bugs in the 2.1 release cycle that would have been caught earlier had we had this feature enabled, and I would be surprised if we don't see some more once it gets released into the wild as a result of this. There are still bugs in 2.0 that we've fixed in 2.1 that we would certainly have caught earlier. Enforcing correctness from other avenues is a strong secondary concern. This isn't a point of optimisation, we're talking about providing an unsafe PIT feature (and we've already got a ticket filed for removing forking), and also more importantly risking an unsafe regular _replay_. I disagree that hardware problem causing checksum mismatch shouldn't block startup - in this case you may have alternative copies of the data that are not corrupted, or can choose to analyse the logs yourself to establish what is happening. If you don't care, you set the "don't care" flag; but without the failure you maybe don't even know there are records that haven't been replayed (possibly whole files) > 2.1 multi-dc upgrade errors > --------------------------- > > Key: CASSANDRA-7582 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7582 > Project: Cassandra > Issue Type: Bug > Components: Core > Reporter: Ryan McGuire > Assignee: Benedict > Priority: Critical > Fix For: 2.1.1 > > > Multi-dc upgrade [was working from 2.0 -> 2.1 fairly > recently|http://cassci.datastax.com/job/cassandra_upgrade_dtest/55/testReport/upgrade_through_versions_test/TestUpgrade_from_cassandra_2_0_latest_tag_to_cassandra_2_1_HEAD/], > but is currently failing. > Running > upgrade_through_versions_test.py:TestUpgrade_from_cassandra_2_0_HEAD_to_cassandra_2_1_HEAD.bootstrap_multidc_test > I get the following errors when starting 2.1 upgraded from 2.0: > {code} > ERROR [main] 2014-07-21 23:54:20,862 CommitLog.java:143 - Commit log replay > failed due to replaying a mutation for a missing table. This error can be > ignored by providing -Dcassandra.commitlog.stop_on_missing_tables=false on > the command line > ERROR [main] 2014-07-21 23:54:20,869 CassandraDaemon.java:474 - Exception > encountered during startup > java.lang.RuntimeException: > org.apache.cassandra.db.UnknownColumnFamilyException: Couldn't find > cfId=a1b676f3-0c5d-3276-bfd5-07cf43397004 > at > org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:300) > [main/:na] > at > org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:457) > [main/:na] > at > org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:546) > [main/:na] > Caused by: org.apache.cassandra.db.UnknownColumnFamilyException: Couldn't > find cfId=a1b676f3-0c5d-3276-bfd5-07cf43397004 > at > org.apache.cassandra.db.ColumnFamilySerializer.deserializeCfId(ColumnFamilySerializer.java:164) > ~[main/:na] > at > org.apache.cassandra.db.ColumnFamilySerializer.deserialize(ColumnFamilySerializer.java:97) > ~[main/:na] > at > org.apache.cassandra.db.Mutation$MutationSerializer.deserializeOneCf(Mutation.java:353) > ~[main/:na] > at > org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:333) > ~[main/:na] > at > org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:365) > ~[main/:na] > at > org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:98) > ~[main/:na] > at > org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:137) > ~[main/:na] > at > org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:115) > ~[main/:na] > {code} -- This message was sent by Atlassian JIRA (v6.2#6252)