- ... ExpiringColumn not create any tombstones? Imo this could be safely
done if the columns TTL is = gcgrace.
Yes, if the TTL = gcgrace this would be safe and I'm pretty sure we
use to have a ticket for that (can't find it back with a quick search
but JIRA search suck and I didn't bother
On Mon, Nov 5, 2012 at 2:11 PM, horschi hors...@gmail.com wrote:
I dont know what your approach was back then, but maybe it could be solved
quite easily: When creating tombstones for ExpiringColumns, we could use
the ExpiringColumn.timestamp to set the DeletedColumn.localDeletionTime .
So
As the OP of this thread, it is a big itch for my use case. Repair ends up
streaming tens of gigabytes of data which has expired TTL and has been
compacted away on some nodes but not yet on others. The wasted work is not
nice plus it drives up the memory usage (for bloom filters, indexes, etc)
On Sat, Nov 3, 2012 at 10:23 PM, horschi hors...@gmail.com wrote:
Do you mind if I ask where you stand on making...
- ... ExpiringColumn not create any tombstones? Imo this could be safely
done if the columns TTL is = gcgrace.
Yes, if the TTL = gcgrace this would be safe and I'm pretty sure we
On Fri, Nov 2, 2012 at 10:46 AM, horschi hors...@gmail.com wrote:
might I ask why repair cannot simply ignore anything that is older than
gc-grace? (like Aaron proposed)
Well, actually the merkle tree computation could probably ignore
gcable tombstones without much problem, which might not be
Sure, created CASSANDRA-4905. I understand that these tombstones will be
still streamed though. Thats fine with me.
Do you mind if I ask where you stand on making...
- ... ExpiringColumn not create any tombstones? Imo this could be safely
done if the columns TTL is = gcgrace. That way it is
Hi Sylvain,
might I ask why repair cannot simply ignore anything that is older than
gc-grace? (like Aaron proposed) I agree that repair should not process any
tombstones or anything. But in my mind it sounds reasonable to make repair
ignore timed-out data. Because the timestamp is created on the
On Fri, Nov 2, 2012 at 2:46 AM, horschi hors...@gmail.com wrote:
might I ask why repair cannot simply ignore anything that is older than
gc-grace? (like Aaron proposed) I agree that repair should not process any
tombstones or anything. But in my mind it sounds reasonable to make repair
ignore
IIRC, tombstone timestamps are written by the server, at compaction
time. Therefore if you have RF=X, you have X different timestamps
relative to GCGraceSeconds. I believe there was another thread about
two weeks ago in which Sylvain detailed the problems with what you are
proposing, when
Is this a feature or a bug?
Neither really. Repair doesn't do any gcable tombstone collection and
it would be really hard to change that (besides, it's not his job). So
if you when you run repair there is sstable with tombstone that could
be collected but are not yet, then yes, they will be
On Thu, Nov 1, 2012 at 1:43 AM, Sylvain Lebresne sylv...@datastax.com wrote:
on all your columns), you may want to force a compaction (using the
JMX call forceUserDefinedCompaction()) of that sstable. The goal being
to get read of a maximum of outdated tombstones before running the
repair (you
It seems like CASSANDRA-3442 might be an effective fix for this issue
assuming that I'm reading it correctly. It sounds like the intent is to
automatically compact SSTables when a certain percent of the columns are
gcable by being deleted or with expired tombstones. Is my understanding
correct?
I've been experiencing a behavior that is undesirable and it seems like a
bug that causes a high amount of wasted work.
I have a CF where all columns have a TTL, are generally all inserted in a
very short period of time (less than a second) and are never over-written
or explicitly deleted.
Is this a feature or a bug?
Yes :)
You are probably on a bit of an edge case.
Maybe a purge-able tombstone can be ignored as part of the merkle tree
calculation and skipped from the streaming? (have not checked the code to see
if they already are.)
Can you create a ticket on
14 matches
Mail list logo
