Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5598011F86 for ; Mon, 25 Aug 2014 08:11:39 +0000 (UTC) Received: (qmail 9215 invoked by uid 500); 25 Aug 2014 08:11:32 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 9174 invoked by uid 500); 25 Aug 2014 08:11:32 -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 9164 invoked by uid 500); 25 Aug 2014 08:11:32 -0000 Delivered-To: apmail-incubator-cassandra-user@incubator.apache.org Received: (qmail 9161 invoked by uid 99); 25 Aug 2014 08:11:32 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Aug 2014 08:11:32 +0000 X-ASF-Spam-Status: No, hits=2.0 required=5.0 tests=SPF_NEUTRAL,URI_HEX X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [216.139.236.26] (HELO sam.nabble.com) (216.139.236.26) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Aug 2014 08:11:06 +0000 Received: from jim.nabble.com ([192.168.236.80]) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1XLpMn-0000c5-8k for cassandra-user@incubator.apache.org; Mon, 25 Aug 2014 01:11:05 -0700 Date: Mon, 25 Aug 2014 01:11:05 -0700 (PDT) From: tsi To: cassandra-user@incubator.apache.org Message-ID: <1408954265263-7596454.post@n2.nabble.com> In-Reply-To: <1407935222509-7596278.post@n2.nabble.com> References: <1407843186116-7596245.post@n2.nabble.com> <1407935222509-7596278.post@n2.nabble.com> Subject: Re: Replacing a dead node in Cassandra 2.0.8 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org I read some additional threads concerning outdated snapshots and deleted da= ta so if the VM snapshot is older than gc_grace_seconds I suppose that data deleted meanwhile for which the tombstones have been removed would come bac= k to life again if I just restore the VM from a snapshot being older than gc_grace_seconds. So after restoring the VM snapshot I should make sure Cassandra doesn=E2=80= =99t start up automatically with the outdated snapshot data. Then I could=20 1)either startup the node with the replace_address option (do I still need to clear data directories first to avoid that deleted data comes back to life again?) 2) restore a Cassandra snapshot being not older than gc_grace_seconds by physically replacing SSTables in the data directory (did I get it right tha= t the node must be up for running StorageService or sstableloader?) and run nodetool repair afterwards. Is this correct?=20 tsi wrote > OK, now supposing Cassandra is run in a VM that crashes and I restore it > from a snapshot done some time ago. Data is stored redundantly > (replication factor 3) and I'm using consistency level QUORUM for reads > and writes. That means no data should be lost as the latest data will at > least be stored on another node. Now what do I have to do to sync the > "dead node" again after restoring the VM from the snapshot? Will a > nodetool repair command be sufficient? -- View this message in context: http://cassandra-user-incubator-apache-org.30= 65146.n2.nabble.com/Replacing-a-dead-node-in-Cassandra-2-0-8-tp7596245p7596= 454.html Sent from the cassandra-user@incubator.apache.org mailing list archive at N= abble.com.