Re: Hi Memory consumption with Copy command

[Stefania Alborghetti]

Hi Bhuvan

Support for large datasets in COPY FROM was added by CASSANDRA-11053
, which is available
in 2.1.14, 2.2.6, 3.0.5 and 3.5. Your scenario is valid with this patch
applied.

The 3.0.x and 3.x releases are already available, whilst the other two
releases are due in the next few days. You only need to install an
up-to-date release on the machine where COPY FROM is running.

You may find the setup instructions in this blog

interesting. Specifically, for large datasets, I would highly recommend
installing the Python driver with C extensions, as it will speed things up
considerably. Again, this is only possible with the 11053 patch. Please
ignore the suggestion to also compile the cqlsh copy module itself with C
extensions (Cython), as you may hit CASSANDRA-11574
 in the 3.0.5 and
3.5 releases.

Before CASSANDRA-11053, the parent process was a bottleneck. This is
explained further in  this blog
,
second paragraph in the "worker processes" section. As a workaround, if you
are unable to upgrade, you may try reducing the INGESTRATE and introducing
a few extra worker processes via NUMPROCESSES. Also, the parent process is
overloaded and is therefore not able to report progress correctly.
Therefore, if the progress report is frozen, it doesn't mean the COPY
OPERATION is not making progress.

Do let us know if you still have problems, as this is new functionality.

With best regards,
Stefania


On Sat, Apr 23, 2016 at 6:34 AM, Bhuvan Rawal  wrote:

> Hi,
>
> Im trying to copy a 20 GB CSV file into a 3 node fresh cassandra cluster
> with 32 GB memory each, sufficient disk, RF-1 and durable write false. The
> machine im feeding into is external to the cluster and shares 1GBps line
> and has 16 GB RAM. (We have chosen this setup to possibly reduce CPU and IO
> usage).
>
> Im trying to use COPY command to feed in data. It kicks off well, launches
> a set of processes, does about 50,000 rows per second. But I can see that
> the parent process starts aggregating memory almost of the size of data
> processed and after a point the processes just hang. The parent process was
> consuming 95% system memory when it had processed around 60% data.
>
> I had earlier tried to feed in data from multiple files (Less than 4GB
> each) and it was working as expected.
>
> Is it a valid scenario?
>
> Regards,
> Bhuvan
>



-- 


[image: datastax_logo.png] 

Stefania Alborghetti

Apache Cassandra Software Engineer

|+852 6114 9265| stefania.alborghe...@datastax.com


[image: cassandrasummit.org/Email_Signature]

Re: Most stable version?

[Jason J. W. Williams]

Thanks for the advice Carlos. Do appreciate it.

-J

On Fri, Apr 22, 2016 at 1:23 PM, Carlos Rolo  wrote:

> I do expect 3 to get stable at some point, according to documentation it
> will be the 3.0.x series. But the current 3.x tick-tock,  I would recommend
> a jump into it when Datastax do it. Otherwise, maybe 4 might get stable and
> we could be following similar releases cicles like some software out there,
> even is stable (2 and 4) even is unstable (3 and 5). But this is my
> guessing. Wait for a DSE release on 3.x and use that.
>
> I had problems in earlier 2.2, 2.2.5 seems to be a solid release, but I
> will wait for 2.2.6 before recommending for production. Just to be safe :)
>
> Regards,
>
> Carlos Juzarte Rolo
> Cassandra Consultant / Datastax Certified Architect / Cassandra MVP
>
> Pythian - Love your data
>
> rolo@pythian | Twitter: @cjrolo | Linkedin: *linkedin.com/in/carlosjuzarterolo
> *
> Mobile: +351 91 891 81 00 | Tel: +1 613 565 8696 x1649
> www.pythian.com
>
> On Fri, Apr 22, 2016 at 6:42 PM, Jason Williams  > wrote:
>
>> Hi Carlos,
>>
>> I read your blog post (actually almost everything I can find on tick
>> tock). My understanding has been tick tock will be the only versioning
>> going forward.
>>
>> Or are you suggesting at some point there will be a stable train for 3?
>> (or that 3.x will be bumped to 4.0 when stable)?
>>
>> We're on 2.2.5 and haven't seen any major problems with it.
>>
>> -J
>>
>>
>>
>> Sent via iPhone
>>
>> On Apr 22, 2016, at 03:34, Carlos Rolo  wrote:
>>
>> If you need SASI, you need to use 3.4+. 3.x will always be "unstable" (It
>> is explained why in my blog post). You get those odd versions, but it is
>> not a solid effort to stabilize the platform, otherwise devs would not jump
>> to 3.6, and keep working on 3.5. And then you get 3.7, which might fix some
>> issues of 3.4+, but next month you get 3.8 unstable again... I'm waiting to
>> see where this is going. I only had bad experiences with 3.x series atm.
>>
>> If you want stability (and no new features), you would use 2.1.13.
>>
>> 2.2.x is kind of a mixed bag, no really huge improvements over 2.1.x
>> series and it is still having some issues, so I would stick to 2.1.x
>> series.
>>
>> Regards,
>>
>> Carlos Juzarte Rolo
>> Cassandra Consultant / Datastax Certified Architect / Cassandra MVP
>>
>> Pythian - Love your data
>>
>> rolo@pythian | Twitter: @cjrolo | Linkedin: 
>> *linkedin.com/in/carlosjuzarterolo
>> *
>> Mobile: +351 91 891 81 00 | Tel: +1 613 565 8696 x1649
>> www.pythian.com
>>
>> On Fri, Apr 22, 2016 at 10:16 AM, Jason Williams <
>> jasonjwwilli...@gmail.com> wrote:
>>
>>> My reading of the tick-rock cycle, is that we've moved from a stable
>>> train that receives mostly bug fixes until the next major stable, to one
>>> where every odd minor version is a bug fix-only...likely mostly for the
>>> previous even. The goal being a relatively continuously stable code base in
>>> odd minor versions.
>>>
>>> In that environment where there is no "stable" train, would the right
>>> approach be to pick the feature set needed and then choose the odd minor
>>> where that feature set had been stable for 2-3 previous odd minors.
>>>
>>> For example, SASI was added in 3.4, so 3.5 is the first bug fix only
>>> (odd minor) containing it. By the logic above you wouldn't want to use SASI
>>> in production until 3.9 or later. Or is my logic about how to treat
>>> tick-tock off base?
>>>
>>> -J
>>>
>>>
>>> Sent via iPhone
>>>
>>> On Apr 22, 2016, at 01:46, Satoshi Hikida  wrote:
>>>
>>> Hi,
>>>
>>> I'm also looking for the most stable version of the Cassandra, too. I
>>> read Carlos's blog post. According to his article, I guess 2.1.x is the
>>> most stable version, is it right? I prefer to use the most stable version
>>> rather than many advanced features. For satisfy my purpose, should I use
>>> 2.1.X? or latest 2.2.x is recommended?
>>>
>>> Currently I use 2.2.5, but is the latest 2.1.13 recommended for
>>> production use?
>>>
>>> Regards,
>>> Satoshi
>>>
>>>
>>> On Mon, Apr 18, 2016 at 11:45 PM, Carlos Rolo  wrote:
>>>
 Sorry to resurrect this now, but I don't consider anything after 3.0.x
 stable.

 I wrote a blog post about this to be clear:
 https://www.pythian.com/blog/cassandra-version-production/

 Use it and pick a version based on your needs.

 Regards,

 Carlos Juzarte Rolo
 Cassandra Consultant / Datastax Certified Architect / Cassandra MVP

 Pythian - Love your data

 rolo@pythian | Twitter: @cjrolo | Linkedin: 
 *linkedin.com/in/carlosjuzarterolo
 *
 Mobile: +351 91 891 81 00 | Tel: +1 613 565 8696 x1649
 www.pythian.com

 On Fri, Apr 15, 2016 at 12:44 PM, Jean Tremblay <
 

Re: Most stable version?

[Carlos Rolo]

I do expect 3 to get stable at some point, according to documentation it
will be the 3.0.x series. But the current 3.x tick-tock,  I would recommend
a jump into it when Datastax do it. Otherwise, maybe 4 might get stable and
we could be following similar releases cicles like some software out there,
even is stable (2 and 4) even is unstable (3 and 5). But this is my
guessing. Wait for a DSE release on 3.x and use that.

I had problems in earlier 2.2, 2.2.5 seems to be a solid release, but I
will wait for 2.2.6 before recommending for production. Just to be safe :)

Regards,

Carlos Juzarte Rolo
Cassandra Consultant / Datastax Certified Architect / Cassandra MVP

Pythian - Love your data

rolo@pythian | Twitter: @cjrolo | Linkedin: *linkedin.com/in/carlosjuzarterolo
*
Mobile: +351 91 891 81 00 | Tel: +1 613 565 8696 x1649
www.pythian.com

On Fri, Apr 22, 2016 at 6:42 PM, Jason Williams 
wrote:

> Hi Carlos,
>
> I read your blog post (actually almost everything I can find on tick
> tock). My understanding has been tick tock will be the only versioning
> going forward.
>
> Or are you suggesting at some point there will be a stable train for 3?
> (or that 3.x will be bumped to 4.0 when stable)?
>
> We're on 2.2.5 and haven't seen any major problems with it.
>
> -J
>
>
>
> Sent via iPhone
>
> On Apr 22, 2016, at 03:34, Carlos Rolo  wrote:
>
> If you need SASI, you need to use 3.4+. 3.x will always be "unstable" (It
> is explained why in my blog post). You get those odd versions, but it is
> not a solid effort to stabilize the platform, otherwise devs would not jump
> to 3.6, and keep working on 3.5. And then you get 3.7, which might fix some
> issues of 3.4+, but next month you get 3.8 unstable again... I'm waiting to
> see where this is going. I only had bad experiences with 3.x series atm.
>
> If you want stability (and no new features), you would use 2.1.13.
>
> 2.2.x is kind of a mixed bag, no really huge improvements over 2.1.x
> series and it is still having some issues, so I would stick to 2.1.x
> series.
>
> Regards,
>
> Carlos Juzarte Rolo
> Cassandra Consultant / Datastax Certified Architect / Cassandra MVP
>
> Pythian - Love your data
>
> rolo@pythian | Twitter: @cjrolo | Linkedin: *linkedin.com/in/carlosjuzarterolo
> *
> Mobile: +351 91 891 81 00 | Tel: +1 613 565 8696 x1649
> www.pythian.com
>
> On Fri, Apr 22, 2016 at 10:16 AM, Jason Williams <
> jasonjwwilli...@gmail.com> wrote:
>
>> My reading of the tick-rock cycle, is that we've moved from a stable
>> train that receives mostly bug fixes until the next major stable, to one
>> where every odd minor version is a bug fix-only...likely mostly for the
>> previous even. The goal being a relatively continuously stable code base in
>> odd minor versions.
>>
>> In that environment where there is no "stable" train, would the right
>> approach be to pick the feature set needed and then choose the odd minor
>> where that feature set had been stable for 2-3 previous odd minors.
>>
>> For example, SASI was added in 3.4, so 3.5 is the first bug fix only (odd
>> minor) containing it. By the logic above you wouldn't want to use SASI in
>> production until 3.9 or later. Or is my logic about how to treat tick-tock
>> off base?
>>
>> -J
>>
>>
>> Sent via iPhone
>>
>> On Apr 22, 2016, at 01:46, Satoshi Hikida  wrote:
>>
>> Hi,
>>
>> I'm also looking for the most stable version of the Cassandra, too. I
>> read Carlos's blog post. According to his article, I guess 2.1.x is the
>> most stable version, is it right? I prefer to use the most stable version
>> rather than many advanced features. For satisfy my purpose, should I use
>> 2.1.X? or latest 2.2.x is recommended?
>>
>> Currently I use 2.2.5, but is the latest 2.1.13 recommended for
>> production use?
>>
>> Regards,
>> Satoshi
>>
>>
>> On Mon, Apr 18, 2016 at 11:45 PM, Carlos Rolo  wrote:
>>
>>> Sorry to resurrect this now, but I don't consider anything after 3.0.x
>>> stable.
>>>
>>> I wrote a blog post about this to be clear:
>>> https://www.pythian.com/blog/cassandra-version-production/
>>>
>>> Use it and pick a version based on your needs.
>>>
>>> Regards,
>>>
>>> Carlos Juzarte Rolo
>>> Cassandra Consultant / Datastax Certified Architect / Cassandra MVP
>>>
>>> Pythian - Love your data
>>>
>>> rolo@pythian | Twitter: @cjrolo | Linkedin: 
>>> *linkedin.com/in/carlosjuzarterolo
>>> *
>>> Mobile: +351 91 891 81 00 | Tel: +1 613 565 8696 x1649
>>> www.pythian.com
>>>
>>> On Fri, Apr 15, 2016 at 12:44 PM, Jean Tremblay <
>>> jean.tremb...@zen-innovations.com> wrote:
>>>
 Thank you Jack.
 Jean

 On 14 Apr 2016, at 22:00 , Jack Krupansky 
 wrote:

 Normally, since 3.5 just came out, it would be wise to see if people
 report any problems over the next 

cassandra solr CQL example in java/scala

[Madabhattula Rajesh Kumar]

Hi,

I am new cassandra solr cql. Can you share java program to execute solr
query in cql.

Regards,
Rajesh

Re: Most stable version?

[Jason Williams]

Hi Carlos,

I read your blog post (actually almost everything I can find on tick tock). My 
understanding has been tick tock will be the only versioning going forward.

Or are you suggesting at some point there will be a stable train for 3? (or 
that 3.x will be bumped to 4.0 when stable)?

We're on 2.2.5 and haven't seen any major problems with it. 

-J



Sent via iPhone

> On Apr 22, 2016, at 03:34, Carlos Rolo  wrote:
> 
> If you need SASI, you need to use 3.4+. 3.x will always be "unstable" (It is 
> explained why in my blog post). You get those odd versions, but it is not a 
> solid effort to stabilize the platform, otherwise devs would not jump to 3.6, 
> and keep working on 3.5. And then you get 3.7, which might fix some issues of 
> 3.4+, but next month you get 3.8 unstable again... I'm waiting to see where 
> this is going. I only had bad experiences with 3.x series atm.
> 
> If you want stability (and no new features), you would use 2.1.13.
> 
> 2.2.x is kind of a mixed bag, no really huge improvements over 2.1.x series 
> and it is still having some issues, so I would stick to 2.1.x series. 
> 
> Regards,
> 
> Carlos Juzarte Rolo
> Cassandra Consultant / Datastax Certified Architect / Cassandra MVP
>  
> Pythian - Love your data
> 
> rolo@pythian | Twitter: @cjrolo | Linkedin: linkedin.com/in/carlosjuzarterolo
> Mobile: +351 91 891 81 00 | Tel: +1 613 565 8696 x1649
> www.pythian.com
> 
>> On Fri, Apr 22, 2016 at 10:16 AM, Jason Williams  
>> wrote:
>> My reading of the tick-rock cycle, is that we've moved from a stable train 
>> that receives mostly bug fixes until the next major stable, to one where 
>> every odd minor version is a bug fix-only...likely mostly for the previous 
>> even. The goal being a relatively continuously stable code base in odd minor 
>> versions. 
>> 
>> In that environment where there is no "stable" train, would the right 
>> approach be to pick the feature set needed and then choose the odd minor 
>> where that feature set had been stable for 2-3 previous odd minors. 
>> 
>> For example, SASI was added in 3.4, so 3.5 is the first bug fix only (odd 
>> minor) containing it. By the logic above you wouldn't want to use SASI in 
>> production until 3.9 or later. Or is my logic about how to treat tick-tock 
>> off base?
>> 
>> -J
>> 
>> 
>> Sent via iPhone
>> 
>>> On Apr 22, 2016, at 01:46, Satoshi Hikida  wrote:
>>> 
>>> Hi,
>>> 
>>> I'm also looking for the most stable version of the Cassandra, too. I read 
>>> Carlos's blog post. According to his article, I guess 2.1.x is the most 
>>> stable version, is it right? I prefer to use the most stable version rather 
>>> than many advanced features. For satisfy my purpose, should I use 2.1.X? or 
>>> latest 2.2.x is recommended?
>>> 
>>> Currently I use 2.2.5, but is the latest 2.1.13 recommended for production 
>>> use?
>>> 
>>> Regards,
>>> Satoshi
>>> 
>>> 
 On Mon, Apr 18, 2016 at 11:45 PM, Carlos Rolo  wrote:
 Sorry to resurrect this now, but I don't consider anything after 3.0.x 
 stable.
 
 I wrote a blog post about this to be clear: 
 https://www.pythian.com/blog/cassandra-version-production/
 
 Use it and pick a version based on your needs.
 
 Regards,
 
 Carlos Juzarte Rolo
 Cassandra Consultant / Datastax Certified Architect / Cassandra MVP
  
 Pythian - Love your data
 
 rolo@pythian | Twitter: @cjrolo | Linkedin: 
 linkedin.com/in/carlosjuzarterolo
 Mobile: +351 91 891 81 00 | Tel: +1 613 565 8696 x1649
 www.pythian.com
 
> On Fri, Apr 15, 2016 at 12:44 PM, Jean Tremblay 
>  wrote:
> Thank you Jack.
> Jean
> 
>> On 14 Apr 2016, at 22:00 , Jack Krupansky  
>> wrote:
>> 
>> Normally, since 3.5 just came out, it would be wise to see if people 
>> report any problems over the next few weeks.
>> 
>> But... the new tick-tock release process is designed to assure that 
>> these odd-numbered releases are only incremental bug fixes from the last 
>> even-numbered feature release, which was 3.4. So, 3.5 should be 
>> reasonably stable.
>> 
>> That said, a bug-fix release of 3.0 is probably going to be more stable 
>> than a bug fix release of a more recent feature release (3.4).
>> 
>> Usually it comes down to whether you need any of the new features or 
>> improvements in 3.x, or whether you might want to keep your chosen 
>> release in production for longer than the older 3.0 releases will be in 
>> production.
>> 
>> Ultimately, this is a personality test: Are you adventuresome or 
>> conservative?
>> 
>> To be clear, with the new tick-tock release scheme, 3.5 is designed to 
>> be a stable release.
>> 
>> -- Jack Krupansky
>> 
>>> On Thu, Apr 14, 2016 at 3:23 PM, 

Efficient Paging Option in Wide Rows

[Anuj Wadehra]

Hi,
I have a wide row index table so that I can fetch all row keys corresponding to 
a column value. 
Row of index_table will look like:
ColValue1:bucket1 >> rowkey1, rowkey2.. rowkeyn..ColValue1:bucketn>> 
rowkey1, rowkey2.. rowkeyn
We will have buckets to avoid hotspots. Row keys of main table are random 
numbers and we will never do column slice like:

Select * from index_table where key=xxx and Col > rowkey1 and col < rowkey10
Also, we will ALWAYS fetch all data for a given value of index column. Thus all 
buckets havr to be read.
Each index column value can map to thousands-millions of row keys in main table.
Based on our use case, there are two design choices in front of me:
1. Have large number of buckets/rows for an index column value and have lesser 
data ( around few thousands) in each row.
Thus, every time we want to fetch all row keys for an index col value, we will 
query more rows and for each row we will have to page through data 500 records 
at a time.
2. Have fewer buckets/rows for an index column value.
Every time we want to fetch all row keys for an index col value, we will query 
data less numner of wider rows and then page through each wide row reading 500 
columns at a time.

Which approach is more efficient?
 Approach1: More number of rows with less data in each row.

OR
Approach 2: less number of  rows with more data in each row

Either ways,  we are fetching only 500 records at a time in a query. Even in 
approach 2 (wider rows) , we can query only small data of 500 at a time.

ThanksAnuj

Re: Alternative approach to setting up new DC

[Surbhi Gupta]

Why dont you use nodetool rebuild ?

On 21 April 2016 at 09:16, Jan  wrote:

> Jens;
>
> I am unsure that you need to enable Replication & also use the sstable
> loader.
> You could load the data into the new DC and susbsequently alter the
> keyspace to replicate from the older DC.
>
> Cheers
> Jan
>
>
> 
> On Thu, 4/21/16, Jens Rantil  wrote:
>
>  Subject: Re: Alternative approach to setting up new DC
>  To: user@cassandra.apache.org
>  Date: Thursday, April 21, 2016, 9:00 AM
>
>  Hi,
>  I never got
>  any response here, but just wanted to share that I went to a
>  Cassandra meet-up in Stockholm yesterday where I talked to
>  two knowledgable Cassandra people that verified that the
>  approach below should work. The most important thing is that
>  the backup must be fully imported before gc_grace_seconds
>  after when the backup is taken.
>  As of me, I managed to a get a more
>  stable VPN setup and did not have to go down this
>  path.
>  Cheers,Jens
>
>  On Mon, Apr
>  18, 2016 at 10:15 AM Jens Rantil 
>  wrote:
>  Hi,
>  I am
>  provisioning a new datacenter for an existing cluster. A
>  rather shaky VPN connection is hindering me from making a
>  "nodetool rebuild" bootstrap on the new DC.
>  Interestingly, I have a full fresh database snapshot/backup
>  at the same location as the new DC (transferred outside of
>  the VPN). I am now considering the following
>  approach:Make
>  sure my clients are using the old DC.
>  Provision the new nodes in new
>  DC.
>  ALTER the keyspace to enable
>  replicas on the new DC. This will start replicating all
>  writes from old DC to new DC.
>  Before
>  gc_grace_seconds after operation 3) above, use sstableloader
>  to stream my backup to the new nodes.
>  For
>  safety precaution, do a full repair.
>  Could you see any issues with
>  doing this?
>  Cheers,Jens--
>
>
>
>
>
>
>
>
>  Jens Rantil
>  Backend Developer @ Tink
>  Tink AB, Wallingatan 5, 111 60 Stockholm, Sweden
>  For urgent matters you can reach me at
>  +46-708-84 18
>  32.--
>
>
>
>
>
>
>
>
>  Jens Rantil
>  Backend Developer @ Tink
>  Tink AB, Wallingatan 5, 111 60
>  Stockholm, Sweden
>  For urgent matters you can
>  reach me at +46-708-84 18 32.
>

Re: Most stable version?

[Carlos Rolo]

If you need SASI, you need to use 3.4+. 3.x will always be "unstable" (It
is explained why in my blog post). You get those odd versions, but it is
not a solid effort to stabilize the platform, otherwise devs would not jump
to 3.6, and keep working on 3.5. And then you get 3.7, which might fix some
issues of 3.4+, but next month you get 3.8 unstable again... I'm waiting to
see where this is going. I only had bad experiences with 3.x series atm.

If you want stability (and no new features), you would use 2.1.13.

2.2.x is kind of a mixed bag, no really huge improvements over 2.1.x series
and it is still having some issues, so I would stick to 2.1.x series.

Regards,

Carlos Juzarte Rolo
Cassandra Consultant / Datastax Certified Architect / Cassandra MVP

Pythian - Love your data

rolo@pythian | Twitter: @cjrolo | Linkedin: *linkedin.com/in/carlosjuzarterolo
*
Mobile: +351 91 891 81 00 | Tel: +1 613 565 8696 x1649
www.pythian.com

On Fri, Apr 22, 2016 at 10:16 AM, Jason Williams 
wrote:

> My reading of the tick-rock cycle, is that we've moved from a stable train
> that receives mostly bug fixes until the next major stable, to one where
> every odd minor version is a bug fix-only...likely mostly for the previous
> even. The goal being a relatively continuously stable code base in odd
> minor versions.
>
> In that environment where there is no "stable" train, would the right
> approach be to pick the feature set needed and then choose the odd minor
> where that feature set had been stable for 2-3 previous odd minors.
>
> For example, SASI was added in 3.4, so 3.5 is the first bug fix only (odd
> minor) containing it. By the logic above you wouldn't want to use SASI in
> production until 3.9 or later. Or is my logic about how to treat tick-tock
> off base?
>
> -J
>
>
> Sent via iPhone
>
> On Apr 22, 2016, at 01:46, Satoshi Hikida  wrote:
>
> Hi,
>
> I'm also looking for the most stable version of the Cassandra, too. I read
> Carlos's blog post. According to his article, I guess 2.1.x is the most
> stable version, is it right? I prefer to use the most stable version rather
> than many advanced features. For satisfy my purpose, should I use 2.1.X? or
> latest 2.2.x is recommended?
>
> Currently I use 2.2.5, but is the latest 2.1.13 recommended for production
> use?
>
> Regards,
> Satoshi
>
>
> On Mon, Apr 18, 2016 at 11:45 PM, Carlos Rolo  wrote:
>
>> Sorry to resurrect this now, but I don't consider anything after 3.0.x
>> stable.
>>
>> I wrote a blog post about this to be clear:
>> https://www.pythian.com/blog/cassandra-version-production/
>>
>> Use it and pick a version based on your needs.
>>
>> Regards,
>>
>> Carlos Juzarte Rolo
>> Cassandra Consultant / Datastax Certified Architect / Cassandra MVP
>>
>> Pythian - Love your data
>>
>> rolo@pythian | Twitter: @cjrolo | Linkedin: 
>> *linkedin.com/in/carlosjuzarterolo
>> *
>> Mobile: +351 91 891 81 00 | Tel: +1 613 565 8696 x1649
>> www.pythian.com
>>
>> On Fri, Apr 15, 2016 at 12:44 PM, Jean Tremblay <
>> jean.tremb...@zen-innovations.com> wrote:
>>
>>> Thank you Jack.
>>> Jean
>>>
>>> On 14 Apr 2016, at 22:00 , Jack Krupansky 
>>> wrote:
>>>
>>> Normally, since 3.5 just came out, it would be wise to see if people
>>> report any problems over the next few weeks.
>>>
>>> But... the new tick-tock release process is designed to assure that
>>> these odd-numbered releases are only incremental bug fixes from the last
>>> even-numbered feature release, which was 3.4. So, 3.5 should be reasonably
>>> stable.
>>>
>>> That said, a bug-fix release of 3.0 is probably going to be more stable
>>> than a bug fix release of a more recent feature release (3.4).
>>>
>>> Usually it comes down to whether you need any of the new features or
>>> improvements in 3.x, or whether you might want to keep your chosen release
>>> in production for longer than the older 3.0 releases will be in production.
>>>
>>> Ultimately, this is a personality test: Are you adventuresome or
>>> conservative?
>>>
>>> To be clear, with the new tick-tock release scheme, 3.5 is designed to
>>> be a stable release.
>>>
>>> -- Jack Krupansky
>>>
>>> On Thu, Apr 14, 2016 at 3:23 PM, Jean Tremblay <
>>> jean.tremb...@zen-innovations.com> wrote:
>>>
 Hi,
 Could someone give his opinion on this?
 What should be considered more stable, Cassandra 3.0.5 or Cassandra 3.5?

 Thank you
 Jean

 > On 12 Apr,2016, at 07:00, Jean Tremblay <
 jean.tremb...@zen-innovations.com> wrote:
 >
 > Hi,
 > Which version of Cassandra should considered most stable in the
 version 3?
 > I see two main branch: the branch with the version 3.0.* and the
 tick-tock one 3.*.*.
 > So basically my question is: which one is most stable, version 3.0.5
 or version 3.3?
 > I know odd versions in 

Re: Most stable version?

[Jason Williams]

My reading of the tick-rock cycle, is that we've moved from a stable train that 
receives mostly bug fixes until the next major stable, to one where every odd 
minor version is a bug fix-only...likely mostly for the previous even. The goal 
being a relatively continuously stable code base in odd minor versions. 

In that environment where there is no "stable" train, would the right approach 
be to pick the feature set needed and then choose the odd minor where that 
feature set had been stable for 2-3 previous odd minors. 

For example, SASI was added in 3.4, so 3.5 is the first bug fix only (odd 
minor) containing it. By the logic above you wouldn't want to use SASI in 
production until 3.9 or later. Or is my logic about how to treat tick-tock off 
base?

-J


Sent via iPhone

> On Apr 22, 2016, at 01:46, Satoshi Hikida  wrote:
> 
> Hi,
> 
> I'm also looking for the most stable version of the Cassandra, too. I read 
> Carlos's blog post. According to his article, I guess 2.1.x is the most 
> stable version, is it right? I prefer to use the most stable version rather 
> than many advanced features. For satisfy my purpose, should I use 2.1.X? or 
> latest 2.2.x is recommended?
> 
> Currently I use 2.2.5, but is the latest 2.1.13 recommended for production 
> use?
> 
> Regards,
> Satoshi
> 
> 
>> On Mon, Apr 18, 2016 at 11:45 PM, Carlos Rolo  wrote:
>> Sorry to resurrect this now, but I don't consider anything after 3.0.x 
>> stable.
>> 
>> I wrote a blog post about this to be clear: 
>> https://www.pythian.com/blog/cassandra-version-production/
>> 
>> Use it and pick a version based on your needs.
>> 
>> Regards,
>> 
>> Carlos Juzarte Rolo
>> Cassandra Consultant / Datastax Certified Architect / Cassandra MVP
>>  
>> Pythian - Love your data
>> 
>> rolo@pythian | Twitter: @cjrolo | Linkedin: linkedin.com/in/carlosjuzarterolo
>> Mobile: +351 91 891 81 00 | Tel: +1 613 565 8696 x1649
>> www.pythian.com
>> 
>>> On Fri, Apr 15, 2016 at 12:44 PM, Jean Tremblay 
>>>  wrote:
>>> Thank you Jack.
>>> Jean
>>> 
 On 14 Apr 2016, at 22:00 , Jack Krupansky  wrote:
 
 Normally, since 3.5 just came out, it would be wise to see if people 
 report any problems over the next few weeks.
 
 But... the new tick-tock release process is designed to assure that these 
 odd-numbered releases are only incremental bug fixes from the last 
 even-numbered feature release, which was 3.4. So, 3.5 should be reasonably 
 stable.
 
 That said, a bug-fix release of 3.0 is probably going to be more stable 
 than a bug fix release of a more recent feature release (3.4).
 
 Usually it comes down to whether you need any of the new features or 
 improvements in 3.x, or whether you might want to keep your chosen release 
 in production for longer than the older 3.0 releases will be in production.
 
 Ultimately, this is a personality test: Are you adventuresome or 
 conservative?
 
 To be clear, with the new tick-tock release scheme, 3.5 is designed to be 
 a stable release.
 
 -- Jack Krupansky
 
> On Thu, Apr 14, 2016 at 3:23 PM, Jean Tremblay 
>  wrote:
> Hi,
> Could someone give his opinion on this?
> What should be considered more stable, Cassandra 3.0.5 or Cassandra 3.5?
> 
> Thank you
> Jean
> 
> > On 12 Apr,2016, at 07:00, Jean Tremblay 
> >  wrote:
> >
> > Hi,
> > Which version of Cassandra should considered most stable in the version 
> > 3?
> > I see two main branch: the branch with the version 3.0.* and the 
> > tick-tock one 3.*.*.
> > So basically my question is: which one is most stable, version 3.0.5 or 
> > version 3.3?
> > I know odd versions in tick-took are bug fix.
> > Thanks
> > Jean
>> 
>> 
>> --
>> 
> 

Re: Most stable version?

[Satoshi Hikida]

Hi,

I'm also looking for the most stable version of the Cassandra, too. I read
Carlos's blog post. According to his article, I guess 2.1.x is the most
stable version, is it right? I prefer to use the most stable version rather
than many advanced features. For satisfy my purpose, should I use 2.1.X? or
latest 2.2.x is recommended?

Currently I use 2.2.5, but is the latest 2.1.13 recommended for production
use?

Regards,
Satoshi


On Mon, Apr 18, 2016 at 11:45 PM, Carlos Rolo  wrote:

> Sorry to resurrect this now, but I don't consider anything after 3.0.x
> stable.
>
> I wrote a blog post about this to be clear:
> https://www.pythian.com/blog/cassandra-version-production/
>
> Use it and pick a version based on your needs.
>
> Regards,
>
> Carlos Juzarte Rolo
> Cassandra Consultant / Datastax Certified Architect / Cassandra MVP
>
> Pythian - Love your data
>
> rolo@pythian | Twitter: @cjrolo | Linkedin: *linkedin.com/in/carlosjuzarterolo
> *
> Mobile: +351 91 891 81 00 | Tel: +1 613 565 8696 x1649
> www.pythian.com
>
> On Fri, Apr 15, 2016 at 12:44 PM, Jean Tremblay <
> jean.tremb...@zen-innovations.com> wrote:
>
>> Thank you Jack.
>> Jean
>>
>> On 14 Apr 2016, at 22:00 , Jack Krupansky 
>> wrote:
>>
>> Normally, since 3.5 just came out, it would be wise to see if people
>> report any problems over the next few weeks.
>>
>> But... the new tick-tock release process is designed to assure that these
>> odd-numbered releases are only incremental bug fixes from the last
>> even-numbered feature release, which was 3.4. So, 3.5 should be reasonably
>> stable.
>>
>> That said, a bug-fix release of 3.0 is probably going to be more stable
>> than a bug fix release of a more recent feature release (3.4).
>>
>> Usually it comes down to whether you need any of the new features or
>> improvements in 3.x, or whether you might want to keep your chosen release
>> in production for longer than the older 3.0 releases will be in production.
>>
>> Ultimately, this is a personality test: Are you adventuresome or
>> conservative?
>>
>> To be clear, with the new tick-tock release scheme, 3.5 is designed to be
>> a stable release.
>>
>> -- Jack Krupansky
>>
>> On Thu, Apr 14, 2016 at 3:23 PM, Jean Tremblay <
>> jean.tremb...@zen-innovations.com> wrote:
>>
>>> Hi,
>>> Could someone give his opinion on this?
>>> What should be considered more stable, Cassandra 3.0.5 or Cassandra 3.5?
>>>
>>> Thank you
>>> Jean
>>>
>>> > On 12 Apr,2016, at 07:00, Jean Tremblay <
>>> jean.tremb...@zen-innovations.com> wrote:
>>> >
>>> > Hi,
>>> > Which version of Cassandra should considered most stable in the
>>> version 3?
>>> > I see two main branch: the branch with the version 3.0.* and the
>>> tick-tock one 3.*.*.
>>> > So basically my question is: which one is most stable, version 3.0.5
>>> or version 3.3?
>>> > I know odd versions in tick-took are bug fix.
>>> > Thanks
>>> > Jean
>>>
>>
>>
>>
>
> --
>
>
>
>