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 DDEB5100B5 for ; Mon, 10 Jun 2013 17:41:49 +0000 (UTC) Received: (qmail 6963 invoked by uid 500); 10 Jun 2013 17:41:46 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 6929 invoked by uid 500); 10 Jun 2013 17:41:40 -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 6879 invoked by uid 99); 10 Jun 2013 17:41:39 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Jun 2013 17:41:39 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of edlinuxguru@gmail.com designates 74.125.82.44 as permitted sender) Received: from [74.125.82.44] (HELO mail-wg0-f44.google.com) (74.125.82.44) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Jun 2013 17:41:34 +0000 Received: by mail-wg0-f44.google.com with SMTP id m15so4070823wgh.23 for ; Mon, 10 Jun 2013 10:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=OXX7x48nwEJdkF6WujSRnMOMxFNAaOeLhw2iTgRuZYc=; b=JO4QrdeEtpXIr9xd23sDKP2JQRPgk/XcsY9dvzz6p0jYnGATD4bvFpLgIxNqKx0Mov QrOu5apbRp2jRuHDw8r3aLti4qs3tWL0V0XbUsKqa0Fv5QIF6fQ5SbcB/QdGSeqy1BZw eQw2ijUDhzbvvNebafx1+TZOxUskjFzrlERjTg0YZPFDel2SZW6s3Mn/B9mUpru1XShh 7u1llGvG7XrFDHEpxsubFmg/gtdFkgcvLmRiHSsPSWxkiM6yS/jIrsT5ecRb8CdnmElV QdwPkLrAV5bTTj35/gg9i8yQ/on+bI0HDvGLhcWROFKLEr7QxI0IAUWRientkpN/xa/O 4Yuw== MIME-Version: 1.0 X-Received: by 10.180.182.228 with SMTP id eh4mr5154252wic.42.1370886073762; Mon, 10 Jun 2013 10:41:13 -0700 (PDT) Received: by 10.195.12.115 with HTTP; Mon, 10 Jun 2013 10:41:13 -0700 (PDT) In-Reply-To: References: <1372322D3525455AA2CEAEC5E159FEB4@gmail.com> Date: Mon, 10 Jun 2013 13:41:13 -0400 Message-ID: Subject: Re: Data Loss/Missing With Cassandra From: Edward Capriolo To: "user@cassandra.apache.org" Content-Type: multipart/alternative; boundary=089e016347fa744ca304ded049dc X-Virus-Checked: Checked by ClamAV on apache.org --089e016347fa744ca304ded049dc Content-Type: text/plain; charset=ISO-8859-1 To recover it would be to dump everything then re-insert everything. Another option would be to return all nodes to whatever tokens they were before the switches, since the old data is still there. Either way both recovery options are long,painful, and a good amount of manual steps. I would not want to do either one. On Mon, Jun 10, 2013 at 12:39 PM, Nimi Wariboko Jr wrote: > How can I recover that data? Can I assume they are still in the sstables? > Would doing a sstable2json then reading and reinserting be an optimal > solution? > > On Monday, June 10, 2013 at 9:18 AM, Tyler Hobbs wrote: > > > On Sun, Jun 9, 2013 at 3:19 PM, Nimi Wariboko Jr wrote: > > If I had to do a repair after upping the RF, than that is probably what > caused the data loss. Wish I had been more careful. > > I'm guessing the data is irrevocably lost, I didn't make any any snapshots. > > Would it be possible to figure out if only a certain part of the ring was > effected? That would be helpful in figuring out what data was lost. > > I've done a full repair now, so I'm also guessing that inconsistent data > is now completely gone as well, right? > > > Cassandra doesn't remove data automatically (partially to help prevent > data loss in cases like this). The original node will still have the full > set of data unless you have run a cleanup operation (nodetool cleanup) on > it. > > > -- > Tyler Hobbs > DataStax > > > --089e016347fa744ca304ded049dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
To recover it would be to dump everything then r= e-insert everything.

Another option would be to return all nod= es to whatever tokens they were before the switches, since the old data is = still there.

Either way both recovery options are long,painful, and a good amo= unt of manual steps. I would not want to do either one.
--089e016347fa744ca304ded049dc--