cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Cassandra Wiki] Trivial Update of "DistributedDeletes" by EricTamme
Date Mon, 12 Sep 2011 17:39:36 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.

The "DistributedDeletes" page has been changed by EricTamme:
http://wiki.apache.org/cassandra/DistributedDeletes?action=diff&rev1=6&rev2=7

Comment:
updating info regarding GC tombstones to reflect versions 0.6.8+ where minor compactions GC
tombstones as well

  
  There's one more piece to the problem: how do we know when it's safe to remove tombstones?
In a fully distributed system, we can't. We could add a coordinator like !ZooKeeper, but that
would pollute the simplicity of the design, as well as complicating ops -- then you'd essentially
have two systems to monitor, instead of one. (This is not to say ZK is bad software -- I believe
it is best in class at what it does -- only that it solves a problem that we do not wish to
add to our system.)
  
- So, Cassandra does what distributed systems designers frequently do when confronted with
a problem we don't know how to solve: define some additional constraints that turn it into
one that we do. Here, we defined a constant, GCGraceSeconds, and had each node track tombstone
age locally. Once it has aged past the constant, it can be GC'd during compaction (see [[MemtableSSTable]]).
This means that if you have a node down for longer than GCGraceSeconds, you should treat it
as a failed node and replace it as described in [[Operations]]. The default setting is very
conservative, at 10 days; you can reduce that once you have Anti Entropy configured to your
satisfaction. And of course if you are only running a single Cassandra node, you can reduce
it to zero, and tombstones will be GC'd at the first major compaction.
+ So, Cassandra does what distributed systems designers frequently do when confronted with
a problem we don't know how to solve: define some additional constraints that turn it into
one that we do. Here, we defined a constant, GCGraceSeconds, and had each node track tombstone
age locally. Once it has aged past the constant, it can be GC'd during compaction (see [[MemtableSSTable]]).
This means that if you have a node down for longer than GCGraceSeconds, you should treat it
as a failed node and replace it as described in [[Operations]]. The default setting is very
conservative, at 10 days; you can reduce that once you have Anti Entropy configured to your
satisfaction. And of course if you are only running a single Cassandra node, you can reduce
it to zero, and tombstones will be GC'd at the first major compaction.  Since 0.6.8, minor
compactions also GC tombstones.
  

Mime
View raw message