Hi Jonathan,
Thanks for your response.
We were running a compact at least once a day over the keyspace. The
gc_grace was set to only 1 hour, so from what you said I would expect that
tombstones should be deleted after max 3 days.
When I inspected the data in the SSTables after a compact, some ro
Removing expired columns actually requires two compaction passes: one
to turn the expired column into a tombstone; one to remove the
tombstone after gc_grace_seconds. (See
https://issues.apache.org/jira/browse/CASSANDRA-1537.)
Perhaps CASSANDRA-2786 was causing things to (erroneously) be cleaned
u
Hi Radim,
I am hunting for what I believe is a bug in Cassandra and tombstone
handling that may be triggered by our particular application usage.
I appreciate your attempt to help, but without you actually knowing what
our application is doing and why, your advice to change our application is
poin
Dne 28.3.2012 13:14, Ross Black napsal(a):
Radim,
We are only deleting columns. *Rows are never deleted.*
i suggest to change app to delete rows. try composite keys.
Radim,
We are only deleting columns. *Rows are never deleted.*
We are continually adding new columns that are then deleted. * Existing
columns (deleted or otherwise) are never updated.
*
Ross*
*
On 28 March 2012 13:51, John Laban wrote:
> (Radim: I'm assuming you mean "do not delete already d
(Radim: I'm assuming you mean "do not delete already deleted columns" as
Ross doesn't delete his rows.)
Just to be clear about Ross' situation: he continually inserts columns and
later deletes columns from the same set of rows. As long as he *doesn't* *keep
deleting already-deleted columns* (wh
Dne 27.3.2012 11:13, Ross Black napsal(a):
Any pointers on what I should be looking for in our application that
would be stopping the deletion of tombstones?
do not delete already deleted rows. On read cassandra returns deleted
rows as empty in range slices.
ely and
> irrevocably delete this message and any copies.-Original Message-
> From: Radim Kolar [mailto:h...@filez.com]
> Sent: Sunday, March 25, 2012 13:20
> To: user@cassandra.apache.org
> Subject: Re: tombstones problem with 1.0.8
>
> Scenario 4
> T1 write column
ately and irrevocably delete
this message and any copies.-Original Message-
From: Radim Kolar [mailto:h...@filez.com]
Sent: Sunday, March 25, 2012 13:20
To: user@cassandra.apache.org
Subject: Re: tombstones problem with 1.0.8
Scenario 4
T1 write column
T2 Flush memtable to S1
T3 del row
Scenario 4
T1 write column
T2 Flush memtable to S1
T3 del row
T4 flush memtable to S5
T5 tomstone S5 expires
T6 S5 is compacted but not with S1
Result?
r, please contact the sender immediately and
> irrevocably delete this message and any copies.
>
> *From:* Ross Black [mailto:ross.w.bl...@gmail.com]
> *Sent:* Friday, March 23, 2012 07:16
> *To:* user@cassandra.apache.org
> *Subject:* Re: tombstones problem with 1.0.8
>
message and any copies.-Original Message-
From: Radim Kolar [mailto:h...@filez.com]
Sent: Friday, March 23, 2012 13:28
To: user@cassandra.apache.org
Subject: Re: tombstones problem with 1.0.8
Example:
T1 < T2 < T3
at T1 write column
at T2 delete row
at T3 > tombstone expiration
Example:
T1 < T2 < T3
at T1 write column
at T2 delete row
at T3 > tombstone expiration do compact ( T1 + T2 ) and drop expired
tombstone
column from T1 will be alive again?
> You are explaining that if i have expired row tombstone and there exists
> later timestamp on this row that tombstone is not deleted? If this works that
> way, it will be never deleted.
Exactly. It is merged with new one.
Example 1: a row with 1 column in sstable. delete a row, not a column.
During compaction of selected sstables Cassandra checks the whole Column
Family for the latest timestamp of the column/row, including other
sstables and memtable.
You are explaining that if i have expired row tombstone and there exists
later timestamp on this row that tombstone is not deleted
ror, please contact the sender immediately and irrevocably delete
this message and any copies.
From: Ross Black [mailto:ross.w.bl...@gmail.com]
Sent: Friday, March 23, 2012 07:16
To: user@cassandra.apache.org
Subject: Re: tombstones problem with 1.0.8
Hi Victor,
Thanks for your response.
Is t
Hi Victor,
Thanks for your response.
Is there a possibility that continual deletions during compact could be
blocking removal of the tombstones? The full manual compact takes about 4
hours per node for our data, so there is a large number of deletes
occurring during that time.
This is the descr
Just tested 1.0.8 before upgrading from 1.0.7: tombstones created by TTL or by
delete operation are perfectly deleted after either compaction or cleanup.
Have no idea about any other settings than gc_grace_seconds, check you schema
from cassandra-cli.
Best regards/ Pagarbiai
Viktor Jevdo
18 matches
Mail list logo
