On Mon, Mar 29, 2010 at 8:25 PM, Tatu Saloranta <tsalora...@gmail.com> wrote: > So if I understand entry correctly, answer is yes, they need to be > explicitly handled by Cassandra. > Which means that I would be better off trying to move "cursor" > (earliest timestamp to consider), with maybe leaving shorter window > for slightly off-sync timestamps, if number of deleted entries can > grow to large number. Although, size of tombstoned entries should be > small so perhaps it is not a huge problem if stored entries themselves > are large. > > On a related note: it was mentioned that time period used to determine > how eagerly tombstones can be removed is quite high by default, but > configurable. Risk for reducing that time is that if a node is down > for longer than that, it might not see deletes, leading to ghosts. > But if I do want to reduce time period, one potential work around > would seem to be to always remove nodes that go down for longer > periods of time explicitly, and bootstrap a replacement. This is > probably a heavy operation; but it would seem to work correctly with > respect to this particular problem, since it would only copy "live" > objects from remaining instances, which should not have any ghosts.
Right. We should probably update the explanation in the example configuration with more detail. -Jonathan
