Why is Cassandra ignoring my schema modifications?

StackOverflow https://stackoverflow.com//questions/11658870

  •  11-12-2019
  •  | 
  •  

Question

I'm pretty new to Cassandra. I've had a single-node cluster running for a few days with no problems but today it started ignoring some of my CQL commands. SELECTs work fine but if I run DROP TABLE foo; from cqlsh then nothing happens. After a half-second pause it returns me to the prompt but the table wasn't dropped. The same goes for creating an index using CREATE INDEX.

I'm running in a virtual machine, using the Cassandra distribution from OpenStax on Ubuntu 12.04.

I checked the Cassandra logs and I definitely get output when I run a CREATE INDEX, but no apparent errors:

 CREATE INDEX number_uri_index ON numbers (number);

Produces:

 INFO [MigrationStage:1] 2012-07-25 14:25:59,120 ColumnFamilyStore.java (line 643) Enqueuing flush of Memtable-schema_columnfamilies@15955724(1212/1515 serialized/live bytes, 20 ops)
 INFO [FlushWriter:5] 2012-07-25 14:25:59,122 Memtable.java (line 266) Writing Memtable-schema_columnfamilies@15955724(1212/1515 serialized/live bytes, 20 ops)
 INFO [FlushWriter:5] 2012-07-25 14:25:59,139 Memtable.java (line 307) Completed flushing /var/lib/cassandra/data/system/schema_columnfamilies/system-schema_columnfamilies-hd-50-Data.db (1267 bytes) for commitlog position ReplayPosition(segmentId=140485087964, position=8551)
 INFO [MigrationStage:1] 2012-07-25 14:25:59,141 ColumnFamilyStore.java (line 643) Enqueuing flush of Memtable-schema_columns@7576227(320/400 serialized/live bytes, 5 ops)
 INFO [FlushWriter:5] 2012-07-25 14:25:59,141 Memtable.java (line 266) Writing Memtable-schema_columns@7576227(320/400 serialized/live bytes, 5 ops)
 INFO [FlushWriter:5] 2012-07-25 14:25:59,172 Memtable.java (line 307) Completed flushing /var/lib/cassandra/data/system/schema_columns/system-schema_columns-hd-46-Data.db (367 bytes) for commitlog position ReplayPosition(segmentId=140485087964, position=8551)
Was it helpful?

Solution

Same problem here in a 3 nodes setup. Solved doing the same modification on a second node. Investiganting CASSANDRA jira we discovered that it could be related with the way timestamps are managed by schema related commands and it should be fixed in 1.1.3:

CASSANDRA-4461 CASSANDRA-4432

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top