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
diately and
> irrevocably delete this message and any copies.
>
> *From:* Ross Black [mailto:ross.w.bl...@gmail.com]
> *Sent:* Thursday, March 22, 2012 03:38
> *To:* user@cassandra.apache.org
> *Subject:* tombstones problem with 1.0.8
>
> ** **
>
> Hi,
>
> We recently
March 22, 2012 03:38
To: user@cassandra.apache.org
Subject: tombstones problem with 1.0.8
Hi,
We recently moved from 0.8.2 to 1.0.8 and the behaviour seems to have changed
so that tombstones are now not being deleted.
Our application continually adds and removes columns from Cassandra. We
Hi,
We recently moved from 0.8.2 to 1.0.8 and the behaviour seems to have
changed so that tombstones are now not being deleted.
Our application continually adds and removes columns from Cassandra. We
have set a short gc_grace time (3600) since our application would
automatically delete zombies i
19 matches
Mail list logo
