Answer to the exact question
There is no configuration that forces a cluster‑wide purge of the row cache for a particular partition key after a QUORUM write. The only settings you can change are the local cache parameters in cassandra.yaml (e.g., row_cache_size_in_mb, row_cache_provider, row_cache_save_period, row_cache_keys_to_save), and they affect only the node that receives the write.
Because the row cache is node‑local, a read at ONE can hit a replica that still has the old cached value, even though the write has already reached a QUORUM of replicas. Aligning the consistency level with the cache to avoid stale reads is not possible without either disabling the cache for the affected table or using a read level of ALL.
Likely explanation
- The write coordinator invalidates the cache entry only on the replica that processes the write.
- Other replicas keep the stale entry until they process the write themselves or the entry is evicted.
- Reading at ONE may therefore return the stale cached value.
- Reading at QUORUM or ALL forces a coordination step that masks the stale entry.
Confirmed facts
- No Cassandra setting pushes invalidation to remote replicas.
- Consistency levels below ALL cannot guarantee that a ONE read will bypass a stale cache.
- Disabling the row cache for a table (e.g.,
ALTER TABLE ... WITH caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'};) removes the stale‑cache window.
- Using QUORUM for both writes and reads is the cheapest way to maintain read‑your‑writes semantics while keeping the cache enabled.
Practical steps for your case
Verify current local cache settings:
nodetool getcachecapacity
Run a test: perform a QUORUM write, then issue an ONE read from a replica that is not the write target (connect to that node with cqlsh -e "CONSISTENCY ONE" -e "SELECT * FROM keyspace.table WHERE pk = ?"). If you see the old value, the stale cache is the culprit.
If stale reads are unacceptable, either:
- Disable the row cache for the table:
ALTER TABLE keyspace.table WITH caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'};
- Or raise the read level to QUORUM for all reads that require freshness.
After changes, monitor nodetool info for cache hit/miss ratios to ensure the cache is behaving as expected.
Question for clarification
Which Cassandra version are you running? Some cache‑invalidation timing details differ between 2.x, 3.x, and 4.x releases.
cassandra