Re: Working with legacy data via CQL

On 2014-11-15 01:24, Tyler Hobbs wrote: > What version of cassandra did you originally create the column family > in? Have you made any schema changes to it through cql or > cassandra-cli, or has it always been exactly the same? Oh that's a tough question given that the cluster has been around si

Re: Repair completes successfully but data is still inconsistent

On 14 Nov 2014, at 18:44, André Cruz wrote: > > On 14 Nov 2014, at 18:29, Michael Shuler wrote: >> >> On 11/14/2014 12:12 PM, André Cruz wrote: >>> Some extra info. I checked the backups and on the 8th of November, all 3 >>> replicas had the tombstone of the deleted column. So: >>> >>> 1 Nove

Re: Working with legacy data via CQL

On 2014-11-17 09:56, Erik Forsberg wrote: > On 2014-11-15 01:24, Tyler Hobbs wrote: >> What version of cassandra did you originally create the column family >> in? Have you made any schema changes to it through cql or >> cassandra-cli, or has it always been exactly the same? > > Oh that's a tough

Deduplicating data on a node (RF=1)

Hey all, For legacy reasons we're living with Cassandra 2.0.10 in an RF=1 setup. This is being moved away from ASAP. In the meantime, adding a node recently encountered a Stream Failed error (http://pastie.org/9725846). Cassandra restarted and it seemingly restarted streaming from zero, without ha

Re: Force purging of tombstones

You can use the JMX forceUserDefinedCompaction operation to compact each SSTable individually. https://github.com/hancockks/cassandra-compact-cf On Sat, Nov 1, 2014 at 11:18 AM, Jens Rantil wrote: > Hi, > > I recently ran a migration where I modified (essentially, deleted and > inserted) a lar

IF NOT EXISTS on UPDATE statements?

There’s still a lot of weirdness in CQL. For example, you can do an INSERT with an UPDATE .. .which I’m generally fine with. Kind of make sense. However, with INSERT you can do IF NOT EXISTS. … but you can’t do the same thing on UPDATE. So I foolishly wrote all my code assuming that INSERT/UPD

Re: IF NOT EXISTS on UPDATE statements?

"So I foolishly wrote all my code assuming that INSERT/UPDATE were orthogonal, but now they’re not" There are some subtle differences. INSERT will create marker columns, UPDATE won't touch/modify them. What are marker columns ? Some insights here: http://www.slideshare.net/doanduyhai/cassandra-

Re: Force purging of tombstones

On Mon, Nov 17, 2014 at 1:40 PM, Ken Hancock wrote: > You can use the JMX forceUserDefinedCompaction operation to compact each > SSTable individually. > > https://github.com/hancockks/cassandra-compact-cf > I don't recall why I think this, but I think "cleanup" now also discards expired tombston

Re: Force purging of tombstones

Doesn't repair also get rid of tombstones? Rahul Neelakantan > On Nov 17, 2014, at 5:53 PM, Robert Coli wrote: > >> On Mon, Nov 17, 2014 at 1:40 PM, Ken Hancock wrote: >> You can use the JMX forceUserDefinedCompaction operation to compact each >> SSTable individually. >> >> https://github.co

Re: IF NOT EXISTS on UPDATE statements?

> "you can still do IF on UPDATE though… but it’s not possible to do IF > mycolumn IS NULL" --> If mycolumn = null should work > > Alas.. it doesn’t :-/ -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile

Re: IF NOT EXISTS on UPDATE statements?

Just tested with C* 2.1.1 cqlsh:test> CREATE TABLE simple(id int PRIMARY KEY, val text); cqlsh:test> INSERT INTO simple (id) VALUES (1); cqlsh:test> SELECT * FROM simple ; id | val +-- 1 | null (1 rows) cqlsh:test> UPDATE simple SET val = 'new val' WHERE id=1 *IF val = null*; [appl

Re: Force purging of tombstones

On Mon, Nov 17, 2014 at 3:10 PM, Rahul Neelakantan wrote: > Doesn't repair also get rid of tombstones? > Repair is a non-destructive activity, and therefore cannot purge tombstones. =Rob

Re: IF NOT EXISTS on UPDATE statements?

Oh yes. That will work because a value is already there. I’m talking if the value does not exist. Otherwise I’d have to insert a null first. On Mon, Nov 17, 2014 at 3:30 PM, DuyHai Doan wrote: > Just tested with C* 2.1.1 > > cqlsh:test> CREATE TABLE simple(id int PRIMARY KEY, val text); > cqlsh

Re: Repair completes successfully but data is still inconsistent

On 11/17/2014 05:22 AM, André Cruz wrote: I have checked the logs of the 3 replicas for that period and nothing really jumps out. Still, repairs have been running daily, the log reports that the CF is synced, and as of this moment one of the replicas still returns the zombie column so they don’t

Re: Deduplicating data on a node (RF=1)

On 11/17/2014 02:04 PM, Alain Vandendorpe wrote: Hey all, For legacy reasons we're living with Cassandra 2.0.10 in an RF=1 setup. This is being moved away from ASAP. In the meantime, adding a node recently encountered a Stream Failed error (http://pastie.org/9725846). Cassandra restarted and it

Trying to build Cassandra for FreeBSD 10.1

I've successfully built 2.1.2 for FreeBSD, but the JVM crashes upon start-up. Here's the snippet from the top of the log file (attached) # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x000802422655, pid=76732, tid=34384931840 # Any hints on how

Re: Deduplicating data on a node (RF=1)

If he deletes all the data with RF=1, won't he have data loss? On Mon Nov 17 2014 at 5:14:23 PM Michael Shuler wrote: > On 11/17/2014 02:04 PM, Alain Vandendorpe wrote: > > Hey all, > > > > For legacy reasons we're living with Cassandra 2.0.10 in an RF=1 setup. > > This is being moved away from

Re: Trying to build Cassandra for FreeBSD 10.1

On 11/17/2014 07:19 PM, William Arbaugh wrote: I've successfully built 2.1.2 for FreeBSD, but the JVM crashes upon start-up. Here's the snippet from the top of the log file (attached) # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00080242265

Re: Deduplicating data on a node (RF=1)

On 11/17/2014 07:20 PM, Jonathan Haddad wrote: If he deletes all the data with RF=1, won't he have data loss? Of course, ignore my quick answer, Alain. -- Michael

Re: Trying to build Cassandra for FreeBSD 10.1

Only thing I can see from looking at the exception, is that it looks like - I didn’t disassemble the code from hex - that the “peer” value in the RefCountedMemory object is probably 0 Given that Unsafe.allocateMemory should not return 0 even on allocation failure (which should throw OOM) - thou

Re: Deduplicating data on a node (RF=1)

If the new node never formally joined the cluster (streaming never completed, it never entered UN state), shouldn't that node be safe to scrub and start over again? It shouldn't be taking primary writes while it's bootstrapping, should it? On Mon Nov 17 2014 at 6:34:04 PM Michael Shuler wrote: