cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edward Capriolo <edlinuxg...@gmail.com>
Subject Re: 0.6 to 0.7 upgrade assumptions
Date Tue, 02 Nov 2010 19:49:25 GMT
On Tue, Nov 2, 2010 at 2:49 PM, Gary Dusbabek <gdusbabek@gmail.com> wrote:
> You'll need to convert from storage-conf.xml to cassandra.yaml and
> import your schema at some point.  NEWS.txt outlines the general
> approach (see Upgrading).
>
> Gary.
>
> On Tue, Nov 2, 2010 at 13:31, Erik Onnen <eonnen@gmail.com> wrote:
>> Hello,
>> We're planning an upgrade from 0.6.7 (after it's released) to 0.7.0 (after
>> it's released) and I wanted to validate my assumptions about what can be
>> expected. Obviously I'll need to test my own assumptions but I was hoping
>> for some guidance to make sure my understanding is correct.
>> My core assumptions are:
>> 1) After taking the upstream services offline and inducing a flush on 0.6
>> nodes so that all data is compacted, I should be able to start 0.7 binaries
>> on top of the 0.6 data files with no issue.
>> 2) When upgrading, I can change from RackUnawareStrategy to a
>> PropertyFileSnitch configuration. My understanding is that read repair will
>> kick in for the missing facility replicas at a rate roughly equivalent to
>> the read repair chance.
>> 3) While read repair from #2 is occurring, the now incorrect replica nodes
>> will continue to be capable of servicing requests for the data that has not
>> been migrated to the correct replicas.
>> Thanks!
>> -erik
>
As for your step 1. I believe you should use 'nodetool drain' instead
of nodetool flush as the commit log format is changing.

Mime
View raw message