I wanted to throw out a "solution" of mine . With hinted handoff being guaranteed losing a delete is almost impossible so solutions like this are no longer required, but...
My "solution" is always write deletes at cl.all. if a delete fails at all queue it up, on a message queue, write a log, etc. Then later on have some process consume the log and replay the write the delete at all again. This sounds like a pain but it it really not that bad. if you are using c* you likely already have a message queue or hadoop system. Generally lost deletes is an edge case so you would not expect this backup system to be very busy. On Wednesday, December 28, 2011, Jonas Borgström <jo...@borgstrom.se> wrote: > On 2011-12-28 12:52 , Dominic Williams wrote: >> >> Hmm interesting could be some variation on 3510 (which caught me out). > > Actually after making some further reading of the changelog 2786 looks like a likely culprit. > If I'm reading the jira correctly all versions < 0.8.8 and < 1.0.4 are at risk of getting deleted rows resurrected. > > Hopefully an upgrade to 1.0.6 will stop this problem from increasing but I still need to manually re-delete a bunch of rows. > > https://issues.apache.org/jira/browse/CASSANDRA-2786 > >> Personally I really don't like having to rely on repair to stop deletes >> being undone. If you agree follow this proposal for an alternative >> https://issues.apache.org/jira/browse/CASSANDRA-3620 which also stops >> tombstone build up. > > Thanks, this definitely looks interesting. I'll have a look. > > / Jonas >
