Can't write to row key, even at ALL. Tombstones?

We have a few row keys that aren’t taking any writes, even using both the ALL consistency level to read and write. We can’t insert anything into any column, previously existing or new, using the simplest possible heuristic in cqlsh or cassandra-cli. Our suspicion is that we somehow have a

Multi-Column Slice Query w/ Partial Component of Composite Key

Is there a way to include *multiple* column names in a slice query where one only component of the composite column name key needs to match? For example, if this was a single row - username:0 | username:1 | city:0 | city:1 | other:0| other:1

Re: Notes and questions from performing a large delete

- in the future just grab the output from 'show schema' and add/modify as needed. I did not know this either until it happened to me as well - could probably stand to be a little bit more front-and-center, IMO. On Wed, Dec 4, 2013 at 2:59 PM, Josh Dzielak j...@keen.io (mailto:j...@keen.io

Notes and questions from performing a large delete

We recently had a little Cassandra party I wanted to share and see if anyone has notes to compare. Or can tell us what we did wrong or what we could do better. :) Apologies in advance for the length of the narrative here. Task at hand: Delete about 50% of the rows in a large column family

sstable2json hangs for authenticated keyspace?

Having an issue with sstable2json. It appears to hang when I run it against an SSTable that's part of a keyspace with authentication turned on. Running it against any other keyspace works, and as far as I can tell the only difference between the keyspaces is authentication. Has anyone run into

Re: Schema disagreement under normal conditions, ALTER TABLE hangs

, 2013 at 11:24 AM, Robert Coli wrote: On Mon, Nov 25, 2013 at 6:42 PM, Josh Dzielak j...@keen.io (mailto:j...@keen.io) wrote: Recently we had a strange thing happen. Altering schema (gc_grace_seconds) for a column family resulted in a schema disagreement. 3/4 of nodes got it, 1/4 didn't

Schema disagreement under normal conditions, ALTER TABLE hangs

to do the ALTER TABLE there resulted in hanging. We were eventually able to get schema agreement by restarting nodes, but both the initial disagreement under normal conditions and the hanging ALTER TABLE seem pretty weird. Any ideas here? Sound like a bug? We're on 1.2.8. Thanks, Josh -- Josh

Counter value becomes incorrect after several dozen reads writes

cluster. It's also happened in development. Has anyone seem something like this? It feels almost too strange to be an actual bug but I'm stumped and have been looking at it too long :) Thanks, Josh -- Josh Dzielak VP Engineering • Keen IO Twitter • @dzello (https://twitter.com/dzello

Re: Counter value becomes incorrect after several dozen reads writes

Hi Arthur, This is actually for a column in a counter column family, i.e. CounterColumnType. Will check out that thread though, thanks. Best, Josh -- Josh Dzielak VP Engineering • Keen IO Twitter • @dzello (https://twitter.com/dzello) Mobile • 773-540-5264 On Monday, June 24, 2013

Guaranteeing globally unique TimeUUID's in a high throughput distributed system

Cassandra) where you want to use 'time' as a unique index yet might have multiple records for the same time. So any solutions from other realms could be useful too. -- Josh Dzielak VP Engineering • Keen IO Twitter • @dzello (https://twitter.com/dzello) Mobile • 773-540-5264

Re: Guaranteeing globally unique TimeUUID's in a high throughput distributed system

/UniqueIdGenerator.java http://boundary.com/blog/2012/01/12/flake-a-decentralized-k-ordered-unique-id-generator-in-erlang/ Regards, Ariel On Sat, Mar 16, 2013, at 05:24 PM, Josh Dzielak wrote: I have a system where a client sends me arbitrary JSON events containing a timestamp

Re: Guaranteeing globally unique TimeUUID's in a high throughput distributed system

/process uniqueness tricks you mentioned? Thanks Philip! On Saturday, March 16, 2013 at 2:56 PM, Philip O'Toole wrote: On Sat, Mar 16, 2013 at 2:50 PM, Josh Dzielak j...@keen.io (mailto:j...@keen.io) wrote: Thanks Philip. I see where you are coming from; that'd be much simpler and avoid