[
https://issues.apache.org/jira/browse/CASSANDRA-7602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14080121#comment-14080121
]
Russ Hatch commented on CASSANDRA-7602:
---------------------------------------
This still makes me a bit uneasy, but I think the likely cause is a schema
disagreement during the upgrade. If I have a look at gossipinfo after the first
problem, one node doesn't seem to be part of the same datacenter as the others,
and the schema id differs as well.
This only repro's on a rolling upgrade. A full cluster upgrade is just fine.
> During rolling upgrade to 1.2 some counters are not found
> ---------------------------------------------------------
>
> Key: CASSANDRA-7602
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7602
> Project: Cassandra
> Issue Type: Bug
> Environment: java 1.7
> Reporter: Russ Hatch
> Assignee: Russ Hatch
>
> The cassandra dtest for upgrading with RandomPartitioner is showing a
> potential issue with counters during a mixed-version upgrade.
> The test starts with a 3 node cluster on 1.1 (RF=2).
> In turn, the following is performed on each node:
> * node gets 25k counter updates distributed across 100 counter cells.
> (CL=all)
> * node is drained and shutdown
> * node is updated to 1.2, started up, and upgradesstables is run
> * counter values are checked again (CL=one)
> The steps above succeed for the first node, but fail on the second node. The
> failure isn't because the counters are wrong -- they don't seem to be present
> at all.
> I tried adding an additional flush before the drain, and this actually seems
> to have increased the number of counters not found.
> To run the test with dtest/nose:
> set PRINT_DEBUG=true
> then run nosetests -vs
> upgrade_through_versions_test:TestRandomPartitionerUpgrade.upgrade_test_mixed
--
This message was sent by Atlassian JIRA
(v6.2#6252)
