Re: How to measure the write amplification of C*?

As a follow-up, I'm going to write a simple patch to expose the number of flushed bytes from memtable to JMX, so that we can easily monitor it. Here is the jira: https://issues.apache.org/jira/browse/CASSANDRA-11420 On Thu, Mar 10, 2016 at 12:55 PM, Jack Krupansky

RE: Rack aware question.

The consistency ALL was only for my testing so there could be a logical explanation to this. We use LOCAL_QUORUM in prod. Original message From: Jack Krupansky Date: 3/23/2016 4:56 PM (GMT-08:00) To: user@cassandra.apache.org Subject: Re: Rack aware

Re: Rack aware question.

Agreed with Jack. I don't think there's ever a reason to use CL=ALL in an application in production. I would only use it if I was debugging certain types of consistency problems. On Wed, Mar 23, 2016 at 4:56 PM Jack Krupansky wrote: > CL=ALL also means that you won't

Re: Large number of tombstones without delete or update

Hi Henry, Since new values are written without checking for previous values, the only way to assure that a nulled column blocks a previously valid one is to write a tombstone to occlude whatever value might have been present. I believe there are some recent changes as to the handling of null

Re: Large number of tombstones without delete or update

What is the reason for the tombstone for a brand new insert? Do the fields get written as a whole (both nulls and non-nulls? I understand the rationale for tombstones for deletes and updates but it does not make sense for an insert (I am trying to make sense of it). I understand Cassandra writes

Re: Large number of tombstones without delete or update

In addition to writing null values acting as tombstones, also INSERTing a collection (or UPDATE where you set the collection rather than append to it) are also operations which will create tombstones. On Wed, Mar 23, 2016 at 12:09 PM Robert Coli wrote: > On Wed, Mar 23,

Re: Rack aware question.

CL=ALL also means that you won't have HA (High Availability) - if even a single node goes down, you're out of business. I mean, HA is the fundamental reason for using the rack-aware policy - to assure that each replica is on a separate power supply and network connection so that data can be

RE: Rack aware question.

I ran into the following detail from : https://wiki.apache.org/cassandra/ReadRepair “If a lower ConsistencyLevel than ALL was specified, this is done in the background after returning the data from the closest replica to the client; otherwise, it is done before returning the data.” I set

Re: DataModelling to query date range

Flip the problem over. Instead of storing validTo and validFrom, simply store a valid field and partition by (start, end). This may sound wasteful, but disk is cheap: CREATE TABLE routes ( start text, end text, valid timestamp, PRIMARY KEY ((start, end), valid) ); Now, you can execute something

RE: Rack aware question.

Thanks, Read repair is what I thought must be causing this, so I experimented some more with setting read_repair_chance and dc_local_read_repair_chance on the table to 0, and then 1. Unfortunately, the results were somewhat random depending on which node I ran the queries from. For example,

Re: Rack aware question.

> How come 127.0.0.1 is shown as an endpoint holding the ID when its token range doesn’t contain it ? Does “nodetool ring” shows all token-ranges for a node or just the primary range ? I am thinking its only primary. Can someone confirm ? The primary replica of id=1 is always 127.0.0.3. What

RE: Rack aware question.

Thanks for the pointer – appreciate it. My test is on the latest trunk and slightly different. I am not exactly sure if the behavior I see is expected (in which case, is the recommendation to re-bootstrap just to avoid data movement?) or is the behavior not expected and is a bug. If we don’t

Re: Rack aware question.

Actually, I believe you are seeing the behavior described in the ticket I meant to link to, with the detailed exploration : https://issues.apache.org/jira/browse/CASSANDRA-10238 =Rob On Wed, Mar 23, 2016 at 2:06 PM, Anubhav Kale wrote: > Oh, and the query I ran

DataModelling to query date range

Hi all, I have a table that represents a train timetable and looks a bit like this: CREATE TABLE routes ( start text, end text, validFrom timestamp, validTo timestamp, PRIMARY KEY (start, end, validFrom, validTo) ); In this case validFrom is the date that the route becomes valid and validTo is

Re: Large number of tombstones without delete or update

On Wed, Mar 23, 2016 at 9:50 AM, Ralf Steppacher wrote: > How come I end up with that large a number of tombstones? > Are you inserting NULLs? =Rob

Large number of tombstones without delete or update

Hi all, I started running “stress tests” against my application which writes event data to a local single-node Cassandra cluster (C* v2.2.4). After inserting a couple thousand rows (all for the same partition key) I am starting to get warnings in the C* log informing me about large numbers of

Re: Rack aware question.

I could be wrong on this since I've never actually attempted what you are asking. Based on my understanding of how replica assignment is done, I don't think that just changing the rack on an existing node is a good idea. Changing racks for a node that already contains data would result in that

Re: com.datastax.driver.core.Connection "This should not happen and is likely a bug, please report."

It would be nice for that message (and there is one more like it in the driver) to say something more specific about how/where exactly to "report" the situation. I mean, should users file Jira tickets for those two scenarios or simply email to the Java (or other driver) email lists? The message

Rack aware question.

Hello, Suppose we change the racks on VMs on a running cluster. (We need to do this while running on Azure, because sometimes when the VM gets moved its rack changes). In this situation, new writes will be laid out based on new rack info on appropriate replicas. What happens for existing data

Re: Effectiveness of Scrub Operation vs SSTable previously marked in blacklist

yeah that is most likely a bug, could you file a ticket? On Tue, Mar 22, 2016 at 4:36 AM, Michael Fong < michael.f...@ruckuswireless.com> wrote: > Hi, all, > > > > We recently encountered a scenario under Cassandra 2.0 deployment. > Cassandra detected a corrupted sstable, and when we attempt to

RE: Gossip heartbeat and packet capture

Is this from the 1.1 line, perhaps? In my experience it could be very flappy for no particular reason we could discover. 1.1 is a pretty dusty version. Upgrading into the 2.1 or later would be a good idea. If you have to upgrade in place without down time, you will need to go through many

Re: Re-importing Cassandra dependencies with Ant and IntelliJ 14.03

Doh! Didn't look that far down :) Maybe the "IDE" section should be moved to the top in the wiki? That way, it becomes more visible? (assuming most contributors are interested in setting up the IDE before running ant test, ant codecoverage, etc.) Best Regards, Nishant Kelkar On Wednesday, March

Re: Re-importing Cassandra dependencies with Ant and IntelliJ 14.03

> Is this documented somewhere (in the README.txt, etc.)? It is super useful for first-time Ant users like myself to know this upfront. It's documented in the HowToContribute link you posted initially: https://wiki.apache.org/cassandra/RunningCassandraInIDEA ;) 2016-03-23 2:23 GMT-03:00 Nishant

Gossip heartbeat and packet capture

Hi, all, We are trying to reason the possible scenarios when a C*(v1.x) cluster connection keeps flapping in production. (Two node cluster, each node keeps marking the other node DOWN but came back UP within seconds; multiple times a day) We have checked the load on the cluster i- very light