cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Russ Hatch (JIRA)" <>
Subject [jira] [Created] (CASSANDRA-8130) upgrade tests should run upgradesstables less eagerly
Date Thu, 16 Oct 2014 21:13:34 GMT
Russ Hatch created CASSANDRA-8130:

             Summary: upgrade tests should run upgradesstables less eagerly
                 Key: CASSANDRA-8130
             Project: Cassandra
          Issue Type: Test
            Reporter: Russ Hatch

Currently the cassandra upgrade tests in cassandra-dtest are doing an upgrade then running
upgradesstables soon after. We are missing some potential coverage with the current approach.

Instead of upgrading sstables "early", we should be waiting until absolutely necessary to
run upgradesstables to test the guarantee that a version can read sstables from the previous
version. This will give tests more time to interact with reading previous version sstables
and hopefully increase chances of catching a bug.

Each version of cassandra should be able to read sstables from the previous version (so 2.1.x
can read 2.0.x, but is not guaranteed to read 1.2.x), and therefore can work just fine reading
and writing data. Writes of course will happen in the current sstable version, so old sstables
may be supplanted by current ones over time (subject to write volume and compaction), potentially
obviating the need for an sstable upgrade.

upgradesstables must be run before upgrading when the system could contain sstables from two
versions back since read compatibility is not guaranteed (so we must run upgradesstables before
upgrading to 2.1.x if there is a chance that sstables still exist from 1.2.x; because this
is two versions back).

This is all a long-winded way of saying that we should keep track in the dtests if we are
about to be 2 versions behind for an impending upgrade, and only run upgradesstables at that

This message was sent by Atlassian JIRA

View raw message