Re: Problem while migrating a single node cluster from 2.1 to 3.2

[Jeff Jirsa]

Upgrade from 2.1.9+ directly to 3.0 is supported:

https://github.com/apache/cassandra/blob/cassandra-3.0/NEWS.txt#L83-L85

- Upgrade to 3.0 is supported from Cassandra 2.1 versions greater or equal to 
2.1.9, or Cassandra 2.2 versions greater or equal to 2.2.2. Upgrade from 
Cassandra 2.0 and older versions is not supported.


From:  DuyHai Doan
Reply-To:  "user@cassandra.apache.org"
Date:  Saturday, January 30, 2016 at 3:54 AM
To:  "user@cassandra.apache.org"
Subject:  Re: Problem while migrating a single node cluster from 2.1 to 3.2

You need to upgrade first to C* 2.2 before migrating to C* 3.x 

For each version, read the NEWS.txt file and follow the procedure:

>From 2.1.x to 2.2.x : 
>https://github.com/apache/cassandra/blob/cassandra-2.2/NEWS.txt

>From 2.2.x to 3.x: 
>https://github.com/apache/cassandra/blob/cassandra-3.0/NEWS.txt

On Sat, Jan 30, 2016 at 8:10 AM, Ajaya Agrawal  wrote:
Hi,

I am a newbie when it comes to Cassandra administration and operation. We have 
a single node cluster running 2.1 in EC2 and we are planning to move it to 
better single machine instance and want to run 3.2 on that.

I installed 3.2 on the new machine and created a snapshot of the old cluster 
and then copied over all the relevant directories to the new machine in the 
appropriate directory. Specifically I copied 
"/var/lib/cassandra/data/{keyspace} from old machine to the new machine. Before 
that I created relevant schema in the new cluster. I was hoping that Cassandra 
would see new directories and load up the new copied SSTables automatically. At 
the least I was hoping to see the snapshot created in the old cluster, when I 
did a "nodetool listsnapshots" in the new cluster.

I have also changed the name of the new cluster.

Please help me and let me know if I forgot to add any detail.
 
Cheers,
Ajaya




smime.p7s
Description: S/MIME cryptographic signature

Re: EC2 storage options for C*

[Bryan Cheng]

Yep, that motivated my question "Do you have any idea what kind of disk
performance you need?". If you need the performance, its hard to beat
ephemeral SSD in RAID 0 on EC2, and its a solid, battle tested
configuration. If you don't, though, EBS GP2 will save a _lot_ of headache.

Personally, on small clusters like ours (12 nodes), we've found our choice
of instance dictated much more by the balance of price, CPU, and memory.
We're using GP2 SSD and we find that for our patterns the disk is rarely
the bottleneck. YMMV, of course.

On Fri, Jan 29, 2016 at 7:32 PM, Jeff Jirsa 
wrote:

> If you have to ask that question, I strongly recommend m4 or c4 instances
> with GP2 EBS.  When you don’t care about replacing a node because of an
> instance failure, go with i2+ephemerals. Until then, GP2 EBS is capable of
> amazing things, and greatly simplifies life.
>
> We gave a talk on this topic at both Cassandra Summit and AWS re:Invent:
> https://www.youtube.com/watch?v=1R-mgOcOSd4 It’s very much a viable
> option, despite any old documents online that say otherwise.
>
>
>
> From: Eric Plowe
> Reply-To: "user@cassandra.apache.org"
> Date: Friday, January 29, 2016 at 4:33 PM
> To: "user@cassandra.apache.org"
> Subject: EC2 storage options for C*
>
> My company is planning on rolling out a C* cluster in EC2. We are thinking
> about going with ephemeral SSDs. The question is this: Should we put two in
> RAID 0 or just go with one? We currently run a cluster in our data center
> with 2 250gig Samsung 850 EVO's in RAID 0 and we are happy with the
> performance we are seeing thus far.
>
> Thanks!
>
> Eric
>

Re: Problem while migrating a single node cluster from 2.1 to 3.2

[Jonathan Haddad]

Did you also copy the system keyspaces or did you create the schema
manually?

On Sat, Jan 30, 2016 at 9:39 AM Jeff Jirsa 
wrote:

> Upgrade from 2.1.9+ directly to 3.0 is supported:
>
> https://github.com/apache/cassandra/blob/cassandra-3.0/NEWS.txt#L83-L85
>
> - Upgrade to 3.0 is supported from Cassandra 2.1 versions greater or equal
> to 2.1.9, or Cassandra 2.2 versions greater or equal to 2.2.2. Upgrade from
> Cassandra 2.0 and older versions is not supported.
>
>
> From: DuyHai Doan
> Reply-To: "user@cassandra.apache.org"
> Date: Saturday, January 30, 2016 at 3:54 AM
> To: "user@cassandra.apache.org"
> Subject: Re: Problem while migrating a single node cluster from 2.1 to 3.2
>
> You need to upgrade first to C* 2.2 before migrating to C* 3.x
>
> For each version, read the NEWS.txt file and follow the procedure:
>
> From 2.1.x to 2.2.x :
> https://github.com/apache/cassandra/blob/cassandra-2.2/NEWS.txt
>
> From 2.2.x to 3.x:
> https://github.com/apache/cassandra/blob/cassandra-3.0/NEWS.txt
>
> On Sat, Jan 30, 2016 at 8:10 AM, Ajaya Agrawal  wrote:
>
>> Hi,
>>
>> I am a newbie when it comes to Cassandra administration and operation. We
>> have a single node cluster running 2.1 in EC2 and we are planning to move
>> it to better single machine instance and want to run 3.2 on that.
>>
>> I installed 3.2 on the new machine and created a snapshot of the old
>> cluster and then copied over all the relevant directories to the new
>> machine in the appropriate directory. Specifically I copied
>> "/var/lib/cassandra/data/{keyspace} from old machine to the new machine.
>> Before that I created relevant schema in the new cluster. I was hoping that
>> Cassandra would see new directories and load up the new copied SSTables
>> automatically. At the least I was hoping to see the snapshot created in the
>> old cluster, when I did a "nodetool listsnapshots" in the new cluster.
>>
>> I have also changed the name of the new cluster.
>>
>> Please help me and let me know if I forgot to add any detail.
>>
>> Cheers,
>> Ajaya
>>
>
>

Re: Problem while migrating a single node cluster from 2.1 to 3.2

[DuyHai Doan]

You need to upgrade first to C* 2.2 before migrating to C* 3.x

For each version, read the NEWS.txt file and follow the procedure:

>From 2.1.x to 2.2.x :
https://github.com/apache/cassandra/blob/cassandra-2.2/NEWS.txt

>From 2.2.x to 3.x:
https://github.com/apache/cassandra/blob/cassandra-3.0/NEWS.txt

On Sat, Jan 30, 2016 at 8:10 AM, Ajaya Agrawal  wrote:

> Hi,
>
> I am a newbie when it comes to Cassandra administration and operation. We
> have a single node cluster running 2.1 in EC2 and we are planning to move
> it to better single machine instance and want to run 3.2 on that.
>
> I installed 3.2 on the new machine and created a snapshot of the old
> cluster and then copied over all the relevant directories to the new
> machine in the appropriate directory. Specifically I copied
> "/var/lib/cassandra/data/{keyspace} from old machine to the new machine.
> Before that I created relevant schema in the new cluster. I was hoping that
> Cassandra would see new directories and load up the new copied SSTables
> automatically. At the least I was hoping to see the snapshot created in the
> old cluster, when I did a "nodetool listsnapshots" in the new cluster.
>
> I have also changed the name of the new cluster.
>
> Please help me and let me know if I forgot to add any detail.
>
> Cheers,
> Ajaya
>

Re: EC2 storage options for C*

[John Wong]

For production I'd stick with ephemeral disks (aka instance storage) if you
have running a lot of transaction.
However, for regular small testing/qa cluster, or something you know you
want to reload often, EBS is definitely good enough and we haven't had
issues 99%. The 1% is kind of anomaly where we have flush blocked.

But Jeff, kudo that you are able to use EBS. I didn't go through the video,
do you actually use PIOPS or just standard GP2 in your production cluster?

On Sat, Jan 30, 2016 at 1:28 PM, Bryan Cheng  wrote:

> Yep, that motivated my question "Do you have any idea what kind of disk
> performance you need?". If you need the performance, its hard to beat
> ephemeral SSD in RAID 0 on EC2, and its a solid, battle tested
> configuration. If you don't, though, EBS GP2 will save a _lot_ of headache.
>
> Personally, on small clusters like ours (12 nodes), we've found our choice
> of instance dictated much more by the balance of price, CPU, and memory.
> We're using GP2 SSD and we find that for our patterns the disk is rarely
> the bottleneck. YMMV, of course.
>
> On Fri, Jan 29, 2016 at 7:32 PM, Jeff Jirsa 
> wrote:
>
>> If you have to ask that question, I strongly recommend m4 or c4 instances
>> with GP2 EBS.  When you don’t care about replacing a node because of an
>> instance failure, go with i2+ephemerals. Until then, GP2 EBS is capable of
>> amazing things, and greatly simplifies life.
>>
>> We gave a talk on this topic at both Cassandra Summit and AWS re:Invent:
>> https://www.youtube.com/watch?v=1R-mgOcOSd4 It’s very much a viable
>> option, despite any old documents online that say otherwise.
>>
>>
>>
>> From: Eric Plowe
>> Reply-To: "user@cassandra.apache.org"
>> Date: Friday, January 29, 2016 at 4:33 PM
>> To: "user@cassandra.apache.org"
>> Subject: EC2 storage options for C*
>>
>> My company is planning on rolling out a C* cluster in EC2. We are
>> thinking about going with ephemeral SSDs. The question is this: Should we
>> put two in RAID 0 or just go with one? We currently run a cluster in our
>> data center with 2 250gig Samsung 850 EVO's in RAID 0 and we are happy with
>> the performance we are seeing thus far.
>>
>> Thanks!
>>
>> Eric
>>
>
>

Re: Problem while migrating a single node cluster from 2.1 to 3.2

[Ajaya Agrawal]

Hi Jonathon,

I created the schema manually. I took the schema definition from the old
cluster using "desc {keyspace_name}" and then ran those cql statements in
the new cluster. I didn't do anything with the system keyspaces.

Cheers,
Ajaya

On Sat, Jan 30, 2016 at 11:29 PM, Jonathan Haddad  wrote:

> Did you also copy the system keyspaces or did you create the schema
> manually?
>
> On Sat, Jan 30, 2016 at 9:39 AM Jeff Jirsa 
> wrote:
>
>> Upgrade from 2.1.9+ directly to 3.0 is supported:
>>
>> https://github.com/apache/cassandra/blob/cassandra-3.0/NEWS.txt#L83-L85
>>
>> - Upgrade to 3.0 is supported from Cassandra 2.1 versions greater or
>> equal to 2.1.9, or Cassandra 2.2 versions greater or equal to 2.2.2.
>> Upgrade from Cassandra 2.0 and older versions is not supported.
>>
>>
>> From: DuyHai Doan
>> Reply-To: "user@cassandra.apache.org"
>> Date: Saturday, January 30, 2016 at 3:54 AM
>> To: "user@cassandra.apache.org"
>> Subject: Re: Problem while migrating a single node cluster from 2.1 to
>> 3.2
>>
>> You need to upgrade first to C* 2.2 before migrating to C* 3.x
>>
>> For each version, read the NEWS.txt file and follow the procedure:
>>
>> From 2.1.x to 2.2.x :
>> https://github.com/apache/cassandra/blob/cassandra-2.2/NEWS.txt
>>
>> From 2.2.x to 3.x:
>> https://github.com/apache/cassandra/blob/cassandra-3.0/NEWS.txt
>>
>> On Sat, Jan 30, 2016 at 8:10 AM, Ajaya Agrawal 
>> wrote:
>>
>>> Hi,
>>>
>>> I am a newbie when it comes to Cassandra administration and operation.
>>> We have a single node cluster running 2.1 in EC2 and we are planning to
>>> move it to better single machine instance and want to run 3.2 on that.
>>>
>>> I installed 3.2 on the new machine and created a snapshot of the old
>>> cluster and then copied over all the relevant directories to the new
>>> machine in the appropriate directory. Specifically I copied
>>> "/var/lib/cassandra/data/{keyspace} from old machine to the new machine.
>>> Before that I created relevant schema in the new cluster. I was hoping that
>>> Cassandra would see new directories and load up the new copied SSTables
>>> automatically. At the least I was hoping to see the snapshot created in the
>>> old cluster, when I did a "nodetool listsnapshots" in the new cluster.
>>>
>>> I have also changed the name of the new cluster.
>>>
>>> Please help me and let me know if I forgot to add any detail.
>>>
>>> Cheers,
>>> Ajaya
>>>
>>
>>

flipping ordering of returned query results

[Jan]

Folks; 
Need some advice. We have a time-series application that needs the data being 
returned from C*     to be flipped from the typical column based data to be row 
based. 
example :  C*    data :   A   B  C                     D  E  F 
need returned data to be :                          A  D                     B  
E                    C  F

Any input would be much appreciated. 
thanks,Jan

Cassandra - how to scale over time.

[Richard L. Burton III]

Initially, I want to keep costs fairly tight if possible. I plan to use 3
instances of m1.large servers with 200GB of disk space per instance. The
application will use up this diskspace within the first 4 months. At which
point, I will increase the disk space per node by adding new nodes to the
cluster with larger disks and replace the older instances.

The general idea is to keep the disk lean until I need to expand them to
500GB after which I will just add more new nodes to the cluster.

P.S. I haven't done any benchmarks, but the system won't be too
CPU intensive, so I wanted to expand the capacity of the disks by "doing a
rolling upgrade" until I need to add nodes to the cluster to handle the
large disk spaces (e.g., 500GB per node max) or CPU becomes an issue.

Does this sound like a good solution?

-- 
-Richard L. Burton III
@rburton

Re: flipping ordering of returned query results

[Jack Krupansky]

Could you clarify... is this for pairs of rows, or is it n rows with n
columns, and is n a constant known before the query executes or based on
the presence of non-NULL column values?

And is this always adjacent rows using a clustering key - as opposed to a
partition key which does not guarantee adjacency?


-- Jack Krupansky

On Sat, Jan 30, 2016 at 10:28 PM, Jan  wrote:

> Folks;
>
> Need some advice.
> We have a time-series application that needs the data being returned from
> C* to be flipped from the typical column based data to be row based.
>
> example :
> C*data :   A   B  C
> D  E  F
>
> need returned data to be :
>A  D
> B  E
> C  F
>
>
> Any input would be much appreciated.
>
> thanks,
> Jan
>

Re: Cassandra - how to scale over time.

[Richard L. Burton III]

Ignore this - :)


On Sun, Jan 31, 2016 at 12:00 AM, Richard L. Burton III 
wrote:

> Initially, I want to keep costs fairly tight if possible. I plan to use 3
> instances of m1.large servers with 200GB of disk space per instance. The
> application will use up this diskspace within the first 4 months. At which
> point, I will increase the disk space per node by adding new nodes to the
> cluster with larger disks and replace the older instances.
>
> The general idea is to keep the disk lean until I need to expand them to
> 500GB after which I will just add more new nodes to the cluster.
>
> P.S. I haven't done any benchmarks, but the system won't be too
> CPU intensive, so I wanted to expand the capacity of the disks by "doing a
> rolling upgrade" until I need to add nodes to the cluster to handle the
> large disk spaces (e.g., 500GB per node max) or CPU becomes an issue.
>
> Does this sound like a good solution?
>
> --
> -Richard L. Burton III
> @rburton
>



-- 
-Richard L. Burton III
@rburton