Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 92501 invoked from network); 4 Dec 2010 05:03:55 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 4 Dec 2010 05:03:55 -0000 Received: (qmail 85184 invoked by uid 500); 4 Dec 2010 05:03:52 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 85111 invoked by uid 500); 4 Dec 2010 05:03:52 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 85103 invoked by uid 99); 4 Dec 2010 05:03:51 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 04 Dec 2010 05:03:51 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jbellis@gmail.com designates 74.125.83.42 as permitted sender) Received: from [74.125.83.42] (HELO mail-gw0-f42.google.com) (74.125.83.42) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 04 Dec 2010 05:03:45 +0000 Received: by gwb20 with SMTP id 20so5692909gwb.29 for ; Fri, 03 Dec 2010 21:03:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=hPo/XAkvhiUngJx6qRB8XbjxdSstgPBYV+xLi5X2fNk=; b=YFvSzxYA2y5EeM/wDdoPHaKMYVwOBA6+C4qs3REdvFx7fCLYb+slZoKuJRGgyeQOYf DWx2Vbdk5cn6DrO3gh6OC9XL7prbA3fuuqyQsuMMKaIolHlSfGNbXGptqYlRzbOAHB9j TQtdZ19xV2r417nhgZI3fXn4U3BS9Q112ANs0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=G8BYIOMFNs/GI7OXMNXsTFy4enfs6kHoZ/liIiEbGzYllbdqvyE54JRcA/Dnor5vs/ WIRjeAfiHtJT01aEh8loM41VIXUxuGnWcYfxtSUuu7SzLNb3yxRCIjSVNa4hmZ6tizaJ tKYFqFOWlk2LUUaSVH3qA9/GsQaWWqr9AqinU= MIME-Version: 1.0 Received: by 10.151.109.8 with SMTP id l8mr5032502ybm.372.1291439003934; Fri, 03 Dec 2010 21:03:23 -0800 (PST) Received: by 10.236.97.103 with HTTP; Fri, 3 Dec 2010 21:03:23 -0800 (PST) In-Reply-To: References: Date: Fri, 3 Dec 2010 23:03:23 -0600 Message-ID: Subject: Re: Confused about consistency From: Jonathan Ellis To: user Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org I think you are running into https://issues.apache.org/jira/browse/CASSANDRA-1316, where when an inconsistency on QUORUM/ALL is discovered it always peformed the repair at QUORUM instead of the original CL. Thus, reading at ALL you would see the correct answer on the 2nd read but you weren't guaranteed to see it on the first. This was fixed in 0.6.4 but apparently I botched the merge to the 0.7 branch. I corrected that just now, so when you update, you should be good to go. On Fri, Dec 3, 2010 at 9:19 PM, Dan Hendry wrot= e: > I am seeing fairly strange, behavior in my Cassandra cluster. > Setup > =A0- 3 nodes (lets call them nodes 1 2 and 3) > =A0- RF=3D2 > =A0- A set of servers=A0(producers)=A0which which write data to the clust= er at > consistency level ONE > =A0- A set of servers (consumers/processors) which read data from the clu= ster > at consistency level ALL > =A0- Cassandra 0.7 (recent out of the svn branch, post beta 3) > =A0- Clients use the pelops library > Situation: > =A0- Everything is humming along nicely > =A0- A Cassandra node (say 3) goes down (even with 24 GB of ram, OOM erro= rs > are the bain of my existence) > =A0- Producers continue to happily write to the cluster but consumers sta= rt > complaining by throwing TimeOutExceptions and UnavailableExceptions. > =A0- I stagger out of bed in the middle of the night and restart Cassandr= a on > node 3. > =A0- The consumers stop complaining and get back to business but generate > garbage data for the period node 3 was down. Its almost like half the dat= a > is missing half the time. (Again, I am reading at consistency level ALL). > =A0- I force the consumers to reprocess data for the period node 3 was do= wn. > They generate accurate output which is different from the first time roun= d. > To be explicit, what seems to be happening is first read at consistency A= LL > gives "A,C,E" (for example) and the second read at consistency level ALL > gives "A,B,C,D,E". Is this a Cassandra bug? Is my knowledge of consistenc= y > levels flawed? My understanding is that you could achieve strongly > consistent behavior by writing at ONE and reading at ALL. > After this experience, my theory (uneducated, untested, and > under-researched) is that "strong consistency" applies only to column > values, not the set of columns (or super-columns in this case) which make= up > a row. Any thoughts? --=20 Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com