cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Morton <>
Subject Re: Upgrading from 0.6 to 0.7.0
Date Fri, 21 Jan 2011 21:01:45 GMT
Yup, you can use diff ports and you can give them different cluster names and different seed

After you upgrade the second cluster partition the data should repair across, either via RR
or the HHs that were stored while the first partition was down. Easiest thing would be to
run node tool repair. Then a clean up to remove any leftover data.

AFAIK file formats are compatible. But drain the nodes before upgrading to clear the log.

Can you test this on a non production system?

(we really need to write some upgrade docs:))

On 21/01/2011, at 10:42 PM, Dave Gardner <> wrote:

> What about executing writes against both clusters during the changeover? Interested in
this topic because we're currently thinking about the same thing - how to upgrade to 0.7 without
any interruption. 
> Dave
> On 21 January 2011 09:20, Daniel Josefsson <> wrote:
> No, what I'm thinking of is having two clusters (0.6 and 0.7) running on different ports
so they can't find each other. Or isn't that configurable?
> Then, when I have the two clusters, I could upgrade all of the clients to run against
the new cluster, and finally upgrade the rest of the Cassandra nodes.
> I don't know how the new cluster would cope with having new data in the old cluster when
they are upgraded though.
> /Daniel
> 2011/1/20 Aaron Morton <>
> I'm not sure if your suggesting running a mixed mode cluster there, but AFAIK the changes
to the internode protocol prohibit this. The nodes will probable see each either via gossip,
but the way the messages define their purpose (their verb handler) has been changed.
> Out of interest which is more painful, stopping the cluster and upgrading it or upgrading
your client code?
> Aaron
> On 21/01/2011, at 12:35 AM, Daniel Josefsson <> wrote:
>> In our case our replication factor is more than half the number of nodes in the cluster.
>> Would it be possible to do the following:
>> Upgrade half of them
>> Change Thrift Port and inter-server port (is this the storage_port?)
>> Start them up
>> Upgrade clients one by one
>> Upgrade the the rest of the servers
>> Or might we get some kind of data collision when still writing to the old cluster
as the new storage is being used?
>> /Daniel

View raw message