Re: Compaction not happening

CASSANDRA-9662 definitely sounds like the source of my spikes. Good to know they are fake. Just wish I knew why it won’t compact when 50% of my data has been tombstoned. The other day it shed 10% of its size, and hasn’t grown since, so I guess that’s something. On Sep 28, 2015, at 6:04 PM,

RE: DC's versions compatibility

You CAN run mixed versions in your cluster for a short time when you are upgrading. However, you will most likely not be able to run repairs or any other streaming operations (adding nodes, adding a DC, etc.) while in this state. The advice below is correct. Upgrade your current ring to the

Re: DC's versions compatibility

Hi guys. Thanks for your reply. Is this because the versions are very far from each other (e.g. Different major versions) Or as a rule of thumb, all nodes in a cluster, even in different DC's MUST have the same version? Regards Carlos Alonso | Software Engineer | @calonso

How is the schema applied?

Hi guys. Just wondering how is the schema of a column family applied in write and read paths. As fas as I know the schema is something logical rather than physical. ie: rows are saved on disk along with a header and the actual keyspace/columfamily/column definition is saved in system tables. I

unpredictable sstable size for the same data

Hello. I've copied table from one keyspace into another using spark-cassandra-connector and size of a single sstable data file has ~2x difference: source Data.db file size ~ 450Mb, target ~ 200Mb. Both tables were flushed and compacted before measurement and there is only one sstable per

Re: Should replica placement change after a topology change?

On Tue, Sep 29, 2015 at 9:35 AM, Dongfeng Lu wrote: > Reading Richard's 6 step plan, I felt that I may just need step 1 for my > case, that is "Switch to a different snitch (possibly GPFS), and the > keyspace from SimpleStrategy to NTS but keep it all in one rack." Since I >

Re: Secondary index is causing high CPU load

On Tue, Sep 15, 2015 at 7:44 AM, Tom van den Berge < tom.vandenbe...@gmail.com> wrote: > Read queries on a secondary index are somehow causing an excessively high > CPU load on all nodes in my DC. > ... > What really surprised me is that executing a single query on this > secondary index makes

Re: Secondary index is causing high CPU load

See https://issues.apache.org/jira/browse/CASSANDRA-10414 for an overview of why vnodes are currently less efficient for secondary index queries. On Tue, Sep 29, 2015 at 12:45 PM, Robert Coli wrote: > On Tue, Sep 15, 2015 at 7:44 AM, Tom van den Berge < >

Summit Recap

Here is my particular Summit Recap: http://mrcalonso.com/notes-on-cassandra-summit-2015/ Thanks to everyone for such a great contents and thanks DataStax as well for the great organisation. Cheers! Carlos Alonso | Software Engineer | @calonso