How do I repair what looks to be a corrupt sstable index?

Hi, I don't know how data on at least one of our five nodes in our cluster got bad but what I'm seeing is that the key value output from sstable2json doesn't match the key value that I specify on the command line. For example, I do the following on one of the nodes: bash$:/root Mon Feb 14 12:47:

Re: Deleted columns still coming back; CASSANDRA-{1748,1837} alive in 0.6.x?

oming back to life > > http://wiki.apache.org/cassandra/Operations#Dealing_with_the_consequences_of_nodetool_repair_not_running_within_GCGraceSeconds > > > <http://wiki.apache.org/cassandra/Operations#Dealing_with_the_consequences_of_nodetool_repair_not_running_within_GCGraceSeconds>Why > do you run nodetool flush before the repair ? &

Deleted columns still coming back; CASSANDRA-{1748,1837} alive in 0.6.x?

Hi, Does anyone know if anything similar to https://issues.apache.org/jira/browse/CASSANDRA-1748 or https://issues.apache.org/jira/browse/CASSANDRA-1837 exists in 0.6.x releases? Both of those bugs look like they were introduced, found, and fixed in 0.7, and CASSANDRA-1837 comments indicate that

Has anyone seen column deletes that seem not to actually delete the column?

Hi, I'm trying to figure out what's going on with some column removes that don't seem to be taking hold. This particular test is being done on a single node cluster running 0.6.8 with CL=QUORUM on the writes (which shouldn't matter, I'd think). What I'm seeing in our client log files is that a c

Re: Basic question on distributed delete

Okay, this helps. Cassandra works as I expected in the theoretically "pure" case (writing to the rest of the replicas in a background thread). I asked the question because we've been struggling to understand why we're seeing inconsistencies when we haven't had nodes go down, etc. (However, even

Basic question on distributed delete

I've been searching on wikis and FAQs for a definitive answer to this and haven't found it yet so I thought I'd ask people here. We have a 5-node cluster set up with a replication factor of 3. We're doing write operations (using batch mutates that include deletions) with a QUORUM consistency leve

Re: Node Inconsistency

Hi, Tyler, I'm working with Vram on this project and can respond to your questions. We do indeed continue to get inconsistent data after many read operations. These columns and rowkeys are months old and they have had many reads done on them over that time. Using cassandra-cli we see that on 3

Two threads inserting columns into same key followed by read gets unexpected results

machine as the Cassandra server (running on a dual-core processor). This fails with 0.6.2 code also. Am I wrong in thinking that an insert on a column with consistency level ALL followed immediately by a get_slice should include that column? Thanks Scott McCarty