HH would handle it if it were a FD false positive, but if a node actually does go down then it can miss writes before HH kicks in.
On Wed, Aug 18, 2010 at 9:30 AM, Raj N <raj.cassan...@gmail.com> wrote: > Guys, > Correct me if I am wrong. The whole problem is because a node missed an > update when it was down. Shouldn’t HintedHandoff take care of this case? > > Thanks > -Raj > > -----Original Message----- > From: Jonathan Ellis [mailto:jbel...@gmail.com] > Sent: Wednesday, August 18, 2010 9:22 AM > To: user@cassandra.apache.org > Subject: Re: data deleted came back after 9 days. > > Actually, tombstones are read repaired too -- as long as they are not > expired. But nodetool repair is much less error-prone than relying on RR > and your memory of what deletes you issued. > > Either way, you'd need to increase GCGraceSeconds first to make the > tombstones un-expired first. > > On Wed, Aug 18, 2010 at 12:43 AM, Benjamin Black <b...@b3k.us> wrote: >> On Tue, Aug 17, 2010 at 7:49 PM, Zhong Li <z...@voxeo.com> wrote: >>> Those data were inserted one node, then deleted on a remote node in >>> less than 2 seconds. So it is very possible some node lost tombstone >>> when connection lost. >>> My question, is a ConstencyLevel.ALL read can retrieve lost tombstone >>> back instead of repair? >>> >> >> No. Read repair does not replay operations. You must run nodetool >> repair. >> >> >> b >> > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of Riptano, the source for professional Cassandra support > http://riptano.com > -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
