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 23E7B10490 for ; Wed, 26 Feb 2014 14:19:43 +0000 (UTC) Received: (qmail 48335 invoked by uid 500); 26 Feb 2014 14:19:38 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 48257 invoked by uid 500); 26 Feb 2014 14:19:33 -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 48077 invoked by uid 99); 26 Feb 2014 14:19:21 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Feb 2014 14:19:21 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_IMAGE_ONLY_28,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_REMOTE_IMAGE X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jlacefield@datastax.com designates 209.85.220.176 as permitted sender) Received: from [209.85.220.176] (HELO mail-vc0-f176.google.com) (209.85.220.176) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Feb 2014 14:19:16 +0000 Received: by mail-vc0-f176.google.com with SMTP id la4so970311vcb.35 for ; Wed, 26 Feb 2014 06:18:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=xQQhiUrbFp5VFMw+MlqWLb8G5A0PnZlbdtpb2wEoEPY=; b=kL2b9DNN0AgbY6vDl2NxVF6hAsnO8r9gjtVo1yE14yFru59XF3Hqg9Rlm3R0Ojhl3o 9SESdo2A2XR9eVb+kiqs8mSdIGhd/uJ/KUJQXXuqUi0HalidvgqV3GFUpSVH0WdIJM7H eP28qtHxs2kwRrMjYjLa14BKE3kkaqTrIbxhzdDIBr7cQl/V6N3GZQFYW+F9iDWdWTx9 KT1cmKlmyLCFy2vds3NMxT3JRNbS6JexDeHrdOB6F7VRia5i4K5OmNdY6dnp1jh5l3kk 8Rkv8STOArihc9WvXnlrZQHlGqFeAtnAONJIvOvi7gEoqkNR5WE/ab0Au2ZnCB8TjGtr WCWA== X-Gm-Message-State: ALoCoQkNXeoq4sqBEJ5o9zyrjgSx9flpUeECoCHCNV2RdW7G4OIHl7Hly9RfeSYLHNAKI/KFjVvh MIME-Version: 1.0 X-Received: by 10.58.230.136 with SMTP id sy8mr163660vec.59.1393424334939; Wed, 26 Feb 2014 06:18:54 -0800 (PST) Received: by 10.53.4.3 with HTTP; Wed, 26 Feb 2014 06:18:54 -0800 (PST) In-Reply-To: References: Date: Wed, 26 Feb 2014 09:18:54 -0500 Message-ID: Subject: Re: Cassandra nodetool status result after restoring snapshot From: Jonathan Lacefield To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=047d7bdc7a4a817e3504f34fe210 X-Virus-Checked: Checked by ClamAV on apache.org --047d7bdc7a4a817e3504f34fe210 Content-Type: text/plain; charset=ISO-8859-1 Hello, That's a large variation between the old and new cluster. Are you sure you pulled over all the SSTables for your keyspaces? Also, did you run a repair after the data move? Do you have a lot of tombstone data in the old cluster that was removed during the migration process? Are you using Opscenter? A quick comparison of cfstats between clusters may help you analyze your situation and help you pinpoint if you are missing any data for a particular keyspace, etc as well. Thanks, Jonathan Jonathan Lacefield Solutions Architect, DataStax (404) 822 3487 On Wed, Feb 26, 2014 at 6:07 AM, Ranking Lekarzy < rankinglekarzy.dev@gmail.com> wrote: > Hi > > I have two separated clusters consist of 4 nodes. One cluster is running > on 1.2.12 and the other one on 2.0.5. I loaded data from first cluster > (1.2.12) to the second one (2.0.5) by copying snapshots between > corresponding nodes. I removed commitlogs, started second cluster and run > nodetool upgradesstables. > After this I expect that nodetool status will give me the same results in > "Load" column on both clusters. Unfortunately it is completely different: > - old cluster: [728.02 GB, 558.24 GB, 787.08 GB, 555.1 GB] > - new cluster: [14.63 GB, 35.98 GB, 18 GB, 38.39 GB] > > When I briefly check data on new cluster it looks fine. But I'm worry > about this difference. Do you have any idea what does it mean? > > Thanks, > Michu > --047d7bdc7a4a817e3504f34fe210 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

=A0 That's a large variation= between the old and new cluster. =A0Are you sure you pulled over all the S= STables for your keyspaces? =A0Also, did you run a repair after the data mo= ve? =A0Do you have a lot of tombstone data in the old cluster that was remo= ved during the migration process? =A0Are you using Opscenter? =A0

=A0 A quick comparison of cfstats between clusters may = help you analyze your situation and help you pinpoint if you are missing an= y data for a particular keyspace, etc as well.

Tha= nks,

Jonathan

Jonathan Lacefield
Solutions Architect,= DataStax
(404) 822 3487






On Wed, Feb 26, 2014 at 6:07 AM, Ranking= Lekarzy <rankinglekarzy.dev@gmail.com> wrote:
Hi

I have two separated clusters consis= t of 4 nodes. One cluster is running on 1.2.12 and the other one on 2.0.5. = I loaded data from first cluster (1.2.12) to the second one (2.0.5) by copy= ing snapshots between corresponding nodes. I removed commitlogs, started se= cond cluster and run nodetool upgradesstables.
After this I expect that nodetool status will give me the same r= esults in "Load" column on both clusters. Unfortunately it is com= pletely different:
- old cluster: [728.02 GB,=A0558.24 GB,=A0787.= 08 GB,=A0555.1 GB]
- new cluster: [14.63 GB, 35.98 GB, 18 GB, 38.39 GB]

When I briefly check data on new cluster it looks fine. But I'm= worry about this difference. Do you have any idea what does it mean?

Thanks,
Michu

--047d7bdc7a4a817e3504f34fe210--