cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aaron morton <aa...@thelastpickle.com>
Subject Re: Concerns about Cassandra upgrade from 1.0.6 to 1.1.X
Date Thu, 12 Jul 2012 22:28:46 GMT
It's always a good idea to have a read of the NEWS.txt file https://github.com/apache/cassandra/blob/cassandra-1.1/NEWS.txt

Cheers
-----------------
Aaron Morton
Freelance Developer
@aaronmorton
http://www.thelastpickle.com

On 12/07/2012, at 5:51 PM, Tyler Hobbs wrote:

> On Wed, Jul 11, 2012 at 8:38 PM, Roshan <codevally@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
> 


Mime
View raw message