On Mon, Mar 29, 2010 at 5:57 PM, Jonathan Ellis <[email protected]> wrote: > Does http://wiki.apache.org/cassandra/FAQ#range_ghosts help?
Thank you for quick answer, and apologies for missing this entry. 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. -+ Tatu +-
