How to suppress datastax warnings for gc_grace_seconds being 0

Viewed 31

We do logged batch inserts and selects against cassandra and always against the same partition and we dont set any null columns therefore we dont need to recover with tombstones. The data has a ttl so it always expire on each node. So we set gc_grace_seconds to 0 but we get a lot of warnings from logged batches. We want to supress only this one warning without supressing all warnings. Is there any way to do so?

On the other hand, i have come across that batch replays also are using gc_grace_seconds if it is shorter than max_hint_window_ms, is that also correct for inserted data? Is there any way that we can end up situations that one node not having the new rows after recovery? In the link below it says only risk of gc_grace_seconds being 0 can be losing the deleted data but we dont delete data so is there still any risk you think? https://docs.datastax.com/en/dse/5.1/cql/cql/cql_reference/cql_commands/cqlCreateTable.html#cqlTableProperties__Gc_grace_seconds

Thanks for the help,

1 Answers

So we set gc_grace_seconds to 0

Setting gc_grace_seconds to zero is a really bad idea. Unless you're running a one-node cluster, you'll eventually start to see old data "zombie" it's way back from a TTL.

i have come across that batch replays also are using gc_grace_seconds if it is shorter than max_hint_window_ms, is that also correct for inserted data?

Yes.

Is there any way that we can end up situations that one node not having the new rows after recovery?

Yes. You could also see TTL'd data come back.

In the link below it says only risk of gc_grace_seconds being 0 can be losing the deleted data but we dont delete data so is there still any risk you think?

TTL data still uses the tombstone mechanism. Those tombstones also need to be replicated. When they're not replicated (node down scenarios) that's when you'll see old data come back.

Is it possible that you point me to a cassandra or datastax official document about how hints uses gc_grace_seconds or why one node needs tomstone in order to expire its own data with ttl?

The official docs have this one covered:

Apache Cassandra Documentation - Compaction: https://cassandra.apache.org/doc/4.1/cassandra/operating/compaction/index.html#ttl

"Once the TTL has expired the data is converted to a tombstone which stays around for at least gc_grace_seconds."

The nuances of tombstones, TTLs, and gc_grace_seconds are further discussed in these posts -

Hinted Handoff and GC Grace Seconds Demystified (TLP is now a part of DataStax) by Radovan Zvoncek: https://thelastpickle.com/blog/2018/03/21/hinted-handoff-gc-grace-demystified.html

Tombstones and Ghost Data Don't Have to be Scary! (I wrote this for DS last year): https://medium.com/building-the-open-data-stack/tombstones-and-ghost-data-dont-have-to-be-scary-with-these-tips-and-tricks-from-datastax-48f3c275b05a

Related