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 27A63C70B for ; Thu, 24 May 2012 20:36:49 +0000 (UTC) Received: (qmail 4026 invoked by uid 500); 24 May 2012 20:36:46 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 3985 invoked by uid 500); 24 May 2012 20:36:46 -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 3977 invoked by uid 99); 24 May 2012 20:36:46 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 May 2012 20:36:46 +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 skrolle@gmail.com designates 209.85.161.172 as permitted sender) Received: from [209.85.161.172] (HELO mail-gg0-f172.google.com) (209.85.161.172) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 May 2012 20:36:40 +0000 Received: by ggnc4 with SMTP id c4so248852ggn.31 for ; Thu, 24 May 2012 13:36:19 -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=+CI/DCnNcbJNa1EYfLuPZSxZW/I3/4RbbX9AmDbg2qg=; b=YXzFWC7DnwNtz4ap3srmHHm/tS3gWqAxBeOqAonIMMvWaGZIy7NfB8ZEwOQF4HEnhK OwCQbAqtAlfpkruGW0g4G1z7dPqBXejAqTPvVUA8GMzAJPooY3UVevtofFRpZk/aaDN5 KKSk1T0+AEqo1ChrIn90nDErUlINOJ0ew21a5GP3Muyar1WDnIGgw6eihOfC9t2G4/1o J7GhG68Q6AhzAsfSRE1/Pa5Npk4T3+4+RcwD8bn66p8IUVJnFGlk9jF5F3u941s8VvaN JG3kb/q+r2b2OV6wCfkiEevSFsWLpuwMRzjvup/GjKvwKTum7ZIiVPYNC7PZWnixOLNl Uw4A== MIME-Version: 1.0 Received: by 10.101.180.32 with SMTP id h32mr297641anp.10.1337891779708; Thu, 24 May 2012 13:36:19 -0700 (PDT) Received: by 10.101.183.5 with HTTP; Thu, 24 May 2012 13:36:19 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 May 2012 22:36:19 +0200 Message-ID: Subject: Re: Migrating from a windows cluster to a linux cluster. From: =?ISO-8859-1?Q?Henrik_Schr=F6der?= To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=001636c928c147064e04c0ce341b X-Virus-Checked: Checked by ClamAV on apache.org --001636c928c147064e04c0ce341b Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 24, 2012 at 9:28 PM, Brandon Williams wrote: > > That sounds fine, with the caveat that you can't run sstableloader > from a machine running Cassandra before 1.1, so copying the sstables > manually (assuming both clusters are the same size and have the same > tokens) might be better. > Why is version 1.1 required for sstableloader? We're running 1.0.x on both clusters, but we can of course upgrade if that's required. > > The only issue with this is the timestamps of the data and tombstones in > > each sstable, will they be preserved by sstableloader? What about > deletes of > > non-existing keys? Will they be stored in the Linux cluster so that when > > sstableloader inserts the key later, it's resolved as being deleted? > > None of that should be a problem. > Excellent, thanks! /Henrik --001636c928c147064e04c0ce341b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, May 24, 2012 at 9:28 PM, Brandon Williams <driftx@gmail.com>= wrote:

That sounds fine, with the caveat that you can't run sstableloade= r
from a machine running Cassandra before 1.1, so copying the sstables
manually (assuming both clusters are the same size and have the same
tokens) might be better.

Why is version 1.1 requir= ed for sstableloader? We're running 1.0.x on both clusters, but we can = of course upgrade if that's required.
=A0
> The only issue with this is the timestamps of the data and tombstones = in
> each sstable, will they be preserved by sstableloader? What about dele= tes of
> non-existing keys? Will they be stored in the Linux cluster so that wh= en
> sstableloader inserts the key later, it's resolved as being delete= d?

None of that should be a problem.

Excellent, thanks!
<= br>
/Henrik
--001636c928c147064e04c0ce341b--