Not able to to delete or update a record in Cassandra 3.11.2 using cqlsh

Viewed 65

I have a column family in Cassandra with the following schema.

CREATE TABLE app_documents (
    key text PRIMARY KEY,
    created_at timestamp,
    created_by text,
    details text,
    id text
) WITH bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND comment = ''
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'}
    AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND crc_check_chance = 1.0
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 0
    AND gc_grace_seconds = 864000
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = '99PERCENTILE';
CREATE INDEX app_documents_id_idx ON app_documents (id);

In this CF I have record with a key 'abc' and i am able to select the record using the query

select * from app_documents WHERE key = 'abc';

Now i am trying to delete or update it using the below queries.

delete from app_documents WHERE key = 'abc';
update app_documents set created_by = 'pd' where key = 'abc';

but the above commands having no impact on the record. Other records in the table are working as expected but only this record is kind of stuck in this state.

My Cassandra setup is a single node only.

1 Answers

Usually this happens when the data in the database has timestamp in the future, and it was confirmed by the doing select writetime(created_by) from app_documents WHERE key = 'abc'; - the record had the timestamp of 9th of August - 2 days in the future. Usual reasons for getting such entries are:

  • clocks on the client machine are off by some amount of time - it's always recommended to have ntp running on the client machines as well, not only on Cassandra servers
  • timestamp is set explicitly by client - this could lead to unpredictable behaviour, and explicit timestamps should be set only when it's required, for example, by business logic, but even in this case it makes sense to have some checks that will prevent inserting the timestamps far in the future
Related