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
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
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
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
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
H, 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
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
