To answer my own question here, we tested this out in QA and then ran in production with no issues
Step 1. Upgrade to 1.2.2 Step 2. Start up all nodes It works great. There was no need to run upgradesstables. That said, we are doing a rolling upgradesstables on every node in production right now(we did test that in QA as well of course). Doing so renames all the *-he-* files to *-ib-* files. 1.2.2 seems to be able to do this without affecting cluster performance as well where 1.1.4, this was a big performance impact(we usually removed the node from the cluster to do it). It is slow but only because we have not raised the mb_throughput for compactions at this point(we may do that overnight though and turn it back down later). So to answer the question of how do you upgrade sstables before starting 1.2.2....you don't...upgrade first and all rows seem to be accessible immediately as it reads the old format...and some nodes even start compacting to the new format before you get to upgrading the tables yourself on those nodes. Also, it should delete the *-he-* files from our testing (though the snapshot ones stick around of course so you have a back up plan...though we are nearing to the point where we will delete those...at least once we are fully on all *-ib-* files. I hope that helps someone who googles for it. Later, Dean On 2/28/13 8:45 AM, "Michael Kjellman" <mkjell...@barracuda.com> wrote: >You won't be able to stream them. You need to run upgradesstables between >majors. > >Best, >Michael > >On Feb 27, 2013, at 11:15 PM, "Michal Michalski" <mich...@opera.com> >wrote: > >> I'm currently migrating 1.1.0 to 1.2.1 and on our small CI cluster, >>that >> I was testing some stuff on, it seems that it's not required to run >> upgradesstables (this doc doesn't mention about it too: >> http://www.datastax.com/docs/1.2/install/upgrading but the previous >> versions did). Of course I'd like to upgrade them sooner or later (in >> case of another C* upgrade or so), but for me it seems like it's just >> going to work ("Cassandra is able to read data files created by the >> previous version, but the inverse is not always true.") and compactions >> will slowly "convert" old-version SSTables to new ones if I don't do it >> manually. >> >> M. >> >> W dniu 27.02.2013 20:40, Hiller, Dean pisze: >>> Hmmmm, wouldn't I have to run upgradesstables BEFORE I start the 1.2.2 >>> node? But running upgradesstables as I recall required cassandra to be >>> running.....so does it somehow understand the old format when it >>>starts I >>> suspect? >>> >>> I am thinking I just keep the node out of the ring while I run the >>> upgradesstables, correct? But of course am not sure how to start a >>>1.2.2 >>> node such that it does not join the cluster. >>> >>> Thanks, >>> Dean >>> >>> On 2/27/13 12:31 PM, "Hiller, Dean" <dean.hil...@nrel.gov> wrote: >>> >>>> Hmmm, I have this info from Aaron, but what about bringing up version >>>> 1.2.2 with thrift off so I can run upgradesstables before I rejoin the >>>> ring? >>>> >>>> Quote from Aaron... >>>> In pre 1.2 add these jvm startup params >>>> >>>> -Dcassandra.join_ring=false >>>> -Dcassandra.start_rpc=false >>>> >>>> >>>> >>>> Thanks, >>>> Dean >>>> >>>> On 2/27/13 12:00 PM, "Michael Kjellman" <mkjell...@barracuda.com> >>>>wrote: >>>> >>>>> Yes, it's required between majors. Which your upgrade would be. >>>>> >>>>> On 2/27/13 10:54 AM, "Hiller, Dean" <dean.hil...@nrel.gov> wrote: >>>>> >>>>>> My script to upgrade our first node in QA is thus (basically, >>>>>>snapshot, >>>>>> drain, stop, then switch over then start)Š >>>>>> >>>>>> #!/bin/bash >>>>>> >>>>>> export NODE=$1 >>>>>> export VERSION=1.1.4 >>>>>> export USER=cassandra >>>>>> >>>>>> #NOTE: This script requires you have cassandra 1.2.2 in >>>>>> /opt/cassandra-1.2.2 but >>>>>> # feel free to modify if you like >>>>>> >>>>>> #Move the newest cassandra.yaml to the node >>>>>> scp cassandra.yaml $USER@$NODE:/opt/cassandra/conf >>>>>> >>>>>> #As cassandra user, snapshot then drain the node >>>>>> # and finally shut down cassandra on that node >>>>>> ssh $USER@$NODE <<\EOF >>>>>> nodetool snapshot $VERSION >>>>>> nodetool drain >>>>>> pkill -f 'java.*cassandra' >>>>>> EOF >>>>>> >>>>>> #Now, our .bashrc for cassandra has /opt/cassandra/bin in it's path >>>>>> # so we unlink and the link to the new cassandra as root since only >>>>>>root >>>>>> has >>>>>> # access to the opt directory. >>>>>> ssh root@$NODE <<\EOF >>>>>> rm /opt/cassandra >>>>>> ln -s /opt/cassandra-1.2.2 /opt/cassandra >>>>>> EOF >>>>>> >>>>>> #We should start cassandra ourselves probably....so we can watch the >>>>>> cluster as it joins the node >>>>>> #especially for the very first node we do... >>>>>> #Now as cassandra user, start up the cassandra node and then do >>>>>>manual >>>>>> health checks >>>>>> #ssh $USER@$NODE <<\EOF >>>>>> # cassandra >>>>>> #EOF >>>>> >>>>> >>>>> Copy, by Barracuda, helps you store, protect, and share all your >>>>>amazing >>>>> >>>>> things. Start today: www.copy.com. >> > >Copy, by Barracuda, helps you store, protect, and share all your amazing >things. Start today: www.copy.com.
