Return-Path: Delivered-To: apmail-cassandra-commits-archive@www.apache.org Received: (qmail 25410 invoked from network); 30 Mar 2010 01:35:48 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 30 Mar 2010 01:35:48 -0000 Received: (qmail 89618 invoked by uid 500); 30 Mar 2010 01:35:48 -0000 Delivered-To: apmail-cassandra-commits-archive@cassandra.apache.org Received: (qmail 89599 invoked by uid 500); 30 Mar 2010 01:35:48 -0000 Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cassandra.apache.org Delivered-To: mailing list commits@cassandra.apache.org Received: (qmail 89591 invoked by uid 99); 30 Mar 2010 01:35:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Mar 2010 01:35:48 +0000 X-ASF-Spam-Status: No, hits=-1167.4 required=10.0 tests=ALL_TRUSTED,AWL,FS_REPLICA X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Mar 2010 01:35:47 +0000 Received: from brutus.apache.org (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 3DCD5234C4AF for ; Tue, 30 Mar 2010 01:35:27 +0000 (UTC) Message-ID: <66777559.568601269912927252.JavaMail.jira@brutus.apache.org> Date: Tue, 30 Mar 2010 01:35:27 +0000 (UTC) From: "Stu Hood (JIRA)" To: commits@cassandra.apache.org Subject: [jira] Commented: (CASSANDRA-924) lost data replica not restored after server restart In-Reply-To: <798522736.541691269842489529.JavaMail.jira@brutus.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CASSANDRA-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851205#action_12851205 ] Stu Hood commented on CASSANDRA-924: ------------------------------------ I think you might have used the wrong version of the patch (I see log entries that I removed in the most recent version). I just deleted the older version, and I've tested that this version works on a 3 node cluster with RF=2. Very sorry to use you like a guinea pig like that, but thank you very much for trying out each version. > lost data replica not restored after server restart > --------------------------------------------------- > > Key: CASSANDRA-924 > URL: https://issues.apache.org/jira/browse/CASSANDRA-924 > Project: Cassandra > Issue Type: Bug > Affects Versions: 0.5, 0.6, 0.6.1, 0.7 > Environment: CentOS 5.2 > Reporter: Jianing hu > Fix For: 0.5, 0.6, 0.6.1, 0.7 > > Attachments: 924-0.5.patch, 924.patch, cs1.log, cs1.log, cs2.log, cs2.log, cs3.log, cs3.log, error.log, error.log, error.log, storage-conf.xml > > > With Replicationfactor=2, if a server is brought down and its data directory wiped out, it doesn't restore its data replica after restart and nodeprobe repair. > Steps to reproduce: > 1) Bring up a cluster with three servers cs1,2,3, with their initial token set to 'foo3', 'foo6', and 'foo9', respectively. ReplicationFactor is set to 2 on all 3. > 2) Insert 9 columns with keys from 'foo1' to 'foo9', and flush. Now I have foo1,2,3,7,8,9 on cs1, foo1,2,3,4,5,6, on cs2, and foo4,5,6,7,8,9 > on cs3. So far so good > 3) Bring down cs3 and wipe out its data directory > 4) Bring up cs3 > 5) run nodeprobe repair Keyspace1 on cs3, the flush > At this point I expect to see cs3 getting its data back. But there's nothing in its data directory. I also tried getting all columns with > ConsistencyLevel::ALL to see if that'll do a read pair. But still cs3's data directory is empty. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.