Apache Cassandra 3.11.6: clustering key error, Undefined column name in table after cass-stress write

Question

I am currently experiencing an issue where I try to SELECT or INSERT specific column data from cassandra and keep getting an undefined column name error, despite the fact that the column name is a clustering key when looking at the table. However, other columns behave normally.

keyspace_name | table_name | column_name | clustering_order | column_name_bytes | kind          | position | type
---------------+------------+-------------+------------------+-------------------+---------------+----------+------
    keyspace1 |  standard1 |          C0 |             none |            0x4330 |        static |       -1 | blob
    keyspace1 |  standard1 |     column1 |              asc |  0x636f6c756d6e31 |    clustering |        0 | text
    keyspace1 |  standard1 |         key |             none |          0x6b6579 | partition_key |        0 | blob
    keyspace1 |  standard1 |       value |             none |      0x76616c7565 |       regular |       -1 | blob

cqlsh> SELECT  "column1" from keyspace1.standard1;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Undefined column name column1"

cqlsh> SELECT  "C0" from keyspace1.standard1;

 C0
------------------------
 0xdc9e1bf05eab897f470a
 0x5ff08459ccd892a25f91
 0x85182fdfe7f86306cd58
 0x10f1dd6febff8cbcf3ad
 0xb8e05320cd1037d6e317

Additionally, when inserting data, despite column1 being "undefined," it is still required as a clustering key

cqlsh> insert into keyspace1.standard1 (key) VALUES (0xcccc) ;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Some clustering keys are missing: column1"

when inserting data into other columns however, behavior is normal

cqlsh> insert into keyspace1.standard1 (key, "C0") VALUES (0xcccc, 0xbbbb) ;  
cqlsh> SELECT  "C0" from keyspace1.standard1;

 C0                      key
 ----------------------- ------------------------
 0xdc9e1bf05eab897f470a 0x37373539364d4f323330
                 0xbbbb                 0xcccc
 0x5ff08459ccd892a25f91 0x4f503030314c35393330
 0x85182fdfe7f86306cd58 0x30503337373039503231
 0x10f1dd6febff8cbcf3ad 0x394e35344e4b34383631
 0xb8e05320cd1037d6e317 0x4f384c4b37394c4f3631

This is after I have run cassandra-stress, and I have run similar tests in 3.11.4 and it worked fine, but when queried the column1 (clustering key) entries were all null, which is something I did not think was possible.

Is this intended behavior that changed from 3.11.4 onwards?

Answer 1

It looks like you are dealing with a compact storage table.

You can verify this in cqlsh:

describe table keyspace1.standard1;

If you see WITH COMPACT STORAGE then you have a compact storage table.

Once you drop the compact storage format from this table, you should be able to select the column column1.

To drop compact storage:

ALTER TABLE keyspace1.standard1 DROP COMPACT STORAGE;

I am not sure how you ended up with your table definition (unless cassandra-stress created it for you). The column column1 is normally found in tables that have been migrated from compact storage.

Normally the following happens when migrating the storage format (for tables that have no clustering column):

• Two new columns column1 text and value blob are added. These columns contain any data written outside the CQL table schema to the Thrift table.
• column1 becomes a clustering column.
• All regular columns become static columns.

More information can be found here: https://docs.datastax.com/en/cql-oss/3.3/cql/cql_using/dropCompactStorage.html