On Wed, Jul 11, 2012 at 8:38 PM, Roshan <codeva...@gmail.com> wrote: > > > Currently we are using Cassandra 1.0.6 in our production system but suffer > with the CASSANDRA-3616 (it is already fixed in 1.0.7 version). > > We thought to upgrade the Cassandra to 1.1.X versions, to get it's new > features, but having some concerns about the upgrade and expert advices are > mostly welcome. > > 1. Can Cassandra 1.1.X identify 1.0.X configurations like SSTables, commit > logs, etc without ant issue? And vise versa. Because if something happens > to > 1.1.X after deployed to production, we want to downgrade to 1.0.6 version > (because that's the versions we tested with our applications). >
1.1 can handle 1.0 data/schemas/etc without a problem, but the reverse is not necessarily true. I don't know what in particular might break if you downgrade from 1.1 to 1.0, but in general, Cassandra does not handle downgrading gracefully; typically the SSTable formats have changed during major releases. If you snapshot prior to upgrading, you can always roll back to that, but you will have lost anything written since the upgrade. > > 2. How do we need to do upgrade process? Currently we have 3 node 1.0.6 > cluster in production. Can we upgrade node by node? If we upgrade node by > node, will the other 1.0.6 nodes identify 1.1.X nodes without any issue? Yes, you can do a rolling upgrade to 1.1, one node at a time. It's usually fine to leave the cluster in a mixed state for a short while as long as you don't do things like repairs, decommissions, or bootstraps, but I wouldn't stay in a mixed state any longer than you have to. It's best to test major upgrades with a second, non-production cluster if that's an option. -- Tyler Hobbs DataStax <http://datastax.com/>
