Hi Alberto,

The gc_grace_seconds value is designed to "exclude" a specific tombstoned (=deleted) record in Cassandra for the time specified in "gc_grace_seconds" from compaction.
This is mainly done to prevent these records from becoming "desynchronized" in case Cassandra nodes go down.
If a node goes down, it does not receive the instruction to write tombstones, but the rest of the Cassandra cluster, which has written the tombstones to disk, may still be up.
Would we immediately trigger compaction, effectively removing the tombstones from the rest of the cluster, we would see an effect where, when the node that was down comes up again, would still have the records in their non-tombstoned, non-deleted form. At that point, we have effectively created "zombie data".

The defaults as of present are 4 hours for items with a TTL, such as trending and a full day for items that do not expire by TTL, which is most of the other data, such as configuration data or alarms.

The defaults are a result of careful consideration. We considered e.g. what downtimes we encounter and what data benefits the most from being fully consistent and compared that to the amount of overhead on the disk the setting caused (i.e. the amount of additional disk space this takes).

Usually, we do not recommend deviating from these values.
Deviations are often only done when the system is has a very fast write/delete load, causing a lot of disk space to be taken up in a short time. Then, diminishing the gc_grace_seconds can potentially help as a temporary measure until the write/delete load can be diminished.

Note: for now, DataMiner sets back the default gc_grace_seconds upon each startup.
We are planning to allow more flexibility for that though.