[
https://issues.apache.org/jira/browse/CASSANDRA-20800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening updated CASSANDRA-20800:
---------------------------------------
Description:
In the past, I found this section of our tombstone documentation confusing.
Since sstables are immutable, how does it 'mark' a row with a tombstone? If the
data is expired, would it not just purge the expired row instead of marking it
with a tombstone?
It seems to be describing a special case where gc_grace_seconds > TTL and the
data is compacted. For example, when the TTL is 1 day and the deafault
gc_grace_seconds is the default of ten days. When this happens, expired values
may be compacted and re-written with a expired flag set to True.
My understanding is that if gc_grace_seconds <= TTL then the expired data would
be purged during compaction and not generate a tombstone record.
[Tombstones: What are
tombstones?|https://cassandra.apache.org/doc/latest/cassandra/managing/operating/compaction/tombstones.html#what-are-tombstones]
{noformat}
Note:
You can also mark a Cassandra row or column with a time-to-live (TTL) value.
After this amount of time has ended, Cassandra marks the object with a
tombstone, and handles it like other tombstoned objects.{noformat}
was:
In the past, I found this section of our tombstone documentation confusing.
Since sstables are immutable, how does it 'mark' a row with a tombstone? If the
data is expired, would it not just purge the expired row instead of marking it
with a tombstone?
It seems to be describing a special case where gc_grace_seconds > TTL and the
data is compacted. For example, when the TTL is 1 day and the deafault
gc_grace_seconds is the default of ten days. When this happens, expired values
may be compacted and re-written with a expired flag set to True.
My understanding is that if gc_grace_seconds <= TTL then the expired data would
be purged during compaction and not generate a tombstone record.
{noformat}
Note:
You can also mark a Cassandra row or column with a time-to-live (TTL) value.
After this amount of time has ended, Cassandra marks the object with a
tombstone, and handles it like other tombstoned objects.{noformat}
> Clarify tombstone documentation on expired TTL values
> -----------------------------------------------------
>
> Key: CASSANDRA-20800
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20800
> Project: Apache Cassandra
> Issue Type: Improvement
> Reporter: Brad Schoening
> Priority: Normal
>
> In the past, I found this section of our tombstone documentation confusing.
> Since sstables are immutable, how does it 'mark' a row with a tombstone? If
> the data is expired, would it not just purge the expired row instead of
> marking it with a tombstone?
> It seems to be describing a special case where gc_grace_seconds > TTL and the
> data is compacted. For example, when the TTL is 1 day and the deafault
> gc_grace_seconds is the default of ten days. When this happens, expired
> values may be compacted and re-written with a expired flag set to True.
> My understanding is that if gc_grace_seconds <= TTL then the expired data
> would be purged during compaction and not generate a tombstone record.
> [Tombstones: What are
> tombstones?|https://cassandra.apache.org/doc/latest/cassandra/managing/operating/compaction/tombstones.html#what-are-tombstones]
> {noformat}
> Note:
> You can also mark a Cassandra row or column with a time-to-live (TTL) value.
> After this amount of time has ended, Cassandra marks the object with a
> tombstone, and handles it like other tombstoned objects.{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
