cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tatsuya Kawano <>
Subject Re: Rolling upgrade
Date Thu, 13 May 2010 10:03:44 GMT

Hi Gary,

Thanks for answering my question. I thought that could be a tough  
question as Cassandra is quickly evolving recently, but it was great  
to know that you guys are always trying to make rolling upgrade  
possible for minor upgrades.

My friend is evaluating Cassandra as an HA alterative of enterprise  
service bus. He found Cassandra can be ideal for receiveing real-time  
feeds from hundreds of systems in the company and passing the feeds to  
Hadoop Map Reduce jobs. I thought it's very helpful for him if he can  
run rolling upgrade for minor bug fixes.


On May 11, 2010, at 10:05 PM, Gary Dusbabek <> wrote:

> On Mon, May 10, 2010 at 17:01, Tatsuya Kawano  
> <> wrote:
>> Hi,
>> Does Cassandra support rolling restart recipe between minor version
>> upgrade? I mean rolling restart is a way to upgrade Cassandra version
>> or change configuration **without** bringing down the whole cluster.
>> The recipe will be something like killing a couple of nodes at a time
>> and starting them again with newer version (or newer configuration.)
> We aim for this, but fell short on the 0.6 -> 0.6.1 upgrade.  A change
> made it in that broker inter-node communication across versions.
> Sorry.
>> To make this possible, I think at least the RPC and SSTable format
>> should be compatible between older and newer versions. Do you have  
>> any
>> plan to change them in the future? Also, there might be some
>> exceptions and certain combinations of versions can't coexist in a
>> cluster (e.g. RPC or SSTable bug in the older version.) It will be
>> great if such incompatibilities are documented in the release note.
> RPC has versioning built in, so clients should be able to communicate
> with servers that share the same major version.  Note that this is not
> the same as the inter-node message format that nodes use to
> communicate with each other.
> The SSTable format has been stable since 0.4 (compatible with 0.5 and
> 0.6).  There are some breaking changes scheduled for 0.7, but none of
> them have made it into trunk yet.
> The commit log disk format has changed and will continue to change
> from version to version.  You should flush it prior to upgrading a
> node.  0.6.1 added 'drain' to the nodetool command to make this
> process easier.
> Gary.
>> Thanks,
>> Tatsuya

View raw message