You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by "Hiller, Dean" <De...@nrel.gov> on 2013/02/27 19:54:40 UTC

is upgradesstables required for 1.1.4 to 1.2.2? (I don't think it is)

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

Re: is upgradesstables required for 1.1.4 to 1.2.2? (I don't think it is)

Posted by "Hiller, Dean" <De...@nrel.gov>.
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" <mk...@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" <mi...@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" <De...@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" <mk...@barracuda.com>
>>>>wrote:
>>>> 
>>>>> Yes, it's required between majors. Which your upgrade would be.
>>>>> 
>>>>> On 2/27/13 10:54 AM, "Hiller, Dean" <De...@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.


Re: is upgradesstables required for 1.1.4 to 1.2.2? (I don't think it is)

Posted by Michael Kjellman <mk...@barracuda.com>.
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" <mi...@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" <De...@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" <mk...@barracuda.com> wrote:
>>> 
>>>> Yes, it's required between majors. Which your upgrade would be.
>>>> 
>>>> On 2/27/13 10:54 AM, "Hiller, Dean" <De...@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.

Re: is upgradesstables required for 1.1.4 to 1.2.2? (I don't think it is)

Posted by Michal Michalski <mi...@opera.com>.
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" <De...@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" <mk...@barracuda.com> wrote:
>>
>>> Yes, it's required between majors. Which your upgrade would be.
>>>
>>> On 2/27/13 10:54 AM, "Hiller, Dean" <De...@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.
>>


Re: is upgradesstables required for 1.1.4 to 1.2.2? (I don't think it is)

Posted by "Hiller, Dean" <De...@nrel.gov>.
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" <De...@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" <mk...@barracuda.com> wrote:
>
>>Yes, it's required between majors. Which your upgrade would be.
>>
>>On 2/27/13 10:54 AM, "Hiller, Dean" <De...@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.
>


Re: is upgradesstables required for 1.1.4 to 1.2.2? (I don't think it is)

Posted by "Hiller, Dean" <De...@nrel.gov>.
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" <mk...@barracuda.com> wrote:

>Yes, it's required between majors. Which your upgrade would be.
>
>On 2/27/13 10:54 AM, "Hiller, Dean" <De...@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.


Re: is upgradesstables required for 1.1.4 to 1.2.2? (I don't think it is)

Posted by Michael Kjellman <mk...@barracuda.com>.
Yes, it's required between majors. Which your upgrade would be.

On 2/27/13 10:54 AM, "Hiller, Dean" <De...@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.