possibilities include 1) you're using something other than rackunwarepartitioner, which is the only one that behaves the way you describe 2) you've moved nodes around w/o running cleanup afterwards
On Sun, Aug 22, 2010 at 10:09 PM, Zhong Li <z...@voxeo.com> wrote: > Today, I checked all nodes data and logs, there are very few nodes reported > connections up/down. I found some data on each nodes which I don't > understand. > > The ReplicationFactor is 2, write Consistency Level is one. Example, the > ring like Node1(Token1)->Node2(Token2)->Node3(Token3)->....... Node1 has > token1, suppose all data with key as token1 should be on Node1 and Node2, > but why I can find some Node1/Node2 data on Node3 also? I dumped the data on > Node3 to my local, red them and found some Node1/Node2's data on the Node3 > and those data should be deleted. > > Why Node3 has Node1/Node2's data? > > Thanks. > > > On Aug 18, 2010, at 10:44 AM, Jonathan Ellis wrote: > >> 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 > > -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
