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 8531210D70 for ; Mon, 7 Apr 2014 20:41:33 +0000 (UTC) Received: (qmail 6516 invoked by uid 500); 7 Apr 2014 20:41:31 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 5783 invoked by uid 500); 7 Apr 2014 20:41:29 -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 5757 invoked by uid 99); 7 Apr 2014 20:41:27 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Apr 2014 20:41:27 +0000 X-ASF-Spam-Status: No, hits=3.1 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,URI_HEX X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of bm3780@gmail.com designates 209.85.213.44 as permitted sender) Received: from [209.85.213.44] (HELO mail-yh0-f44.google.com) (209.85.213.44) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Apr 2014 20:41:22 +0000 Received: by mail-yh0-f44.google.com with SMTP id f10so6404615yha.31 for ; Mon, 07 Apr 2014 13:41:01 -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=Eb7jywA94tumsQPp5y5p1bNg1qXbtOUbWM64KUrZVS0=; b=ecSCKilE6PsgNzTe9Lfz7P7RZO+3uWOSfyIdnyrdvdI5Mx+/DDuHg25JygsnQ8vtLt ViBZY+6hWCDbVogthxLtiZfBPHogeCdK+gVAH+BDTSleyN0BdxNcSSI+w0v4A0Ivlb0W CjoUGe6E20u0ERfiDFETfhNEQE26eZDtDpnoSdjraFwXpWYQqALkVOUST7L4o/a624q3 2pZLweTGdhRt5Rz3YfTGkfPIieoAO/FVo8JP+UHUpPcDn6TpFDfgiTIrNhs6tv/g7S5X KOtP43SE7R2VjqWkGFMvTEjUzZSB82E20c9Q7O9kXqfIYhHXD06s8uG6SECUtbh7gk0z WIlg== MIME-Version: 1.0 X-Received: by 10.236.19.99 with SMTP id m63mr5731191yhm.134.1396903261147; Mon, 07 Apr 2014 13:41:01 -0700 (PDT) Received: by 10.170.216.213 with HTTP; Mon, 7 Apr 2014 13:41:01 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 Apr 2014 16:41:01 -0400 Message-ID: Subject: Re: Migrating to new datacenter From: Brandon McCauslin To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=089e01634dd4aa95d304f679e29d X-Virus-Checked: Checked by ClamAV on apache.org --089e01634dd4aa95d304f679e29d Content-Type: text/plain; charset=ISO-8859-1 Rob, If I read your response in that 1st URL correctly, it seems changing both the snitch and replication strategy at the same time is not advisable and could lead to partial data loss. Is your suggestion of dumping an reloading the data into the new cluster still recommended for these situations? On Mon, Apr 7, 2014 at 2:09 PM, Robert Coli wrote: > On Mon, Apr 7, 2014 at 10:48 AM, Brandon McCauslin wrote: > >> Thanks for the confirmation on the approach. The new dc is not yet >> ready, but while I'm waiting I was thinking about updating the existing >> dc's replication strategy from "SimpleStrategy" to >> "NetworkTopologyStrategy". I also assume I'll need to update my snitch >> from the current SimpleSnitch to PropertyFileSnitch. Here's the steps I'm >> thinking: >> > > Here's a brief explication of how this process works and can be made > safe/testable : > > > http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Ec2Snitch-amp-Other-snitches-td6196494.html > > Consider whether you actually want a rack aware Snitch : > > https://issues.apache.org/jira/browse/CASSANDRA-3810 > > If you do, consider using the Gossiping Property File Snitch : > > https://issues.apache.org/jira/browse/CASSANDRA-1974 > > =Rob > > --089e01634dd4aa95d304f679e29d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Rob,

If I read your response in that 1s= t URL correctly, it seems changing both the snitch and replication strategy= at the same time is not advisable and could lead to partial data loss. =A0= Is your suggestion of dumping an reloading the data into the new cluster st= ill recommended for these situations?


On Mon,= Apr 7, 2014 at 2:09 PM, Robert Coli <rcoli@eventbrite.com> wrote:
=
On Mon, Apr 7, 2014 at 10:48 AM,= Brandon McCauslin <bm3780@gmail.com> wrote:
Thanks for the confirmation on the approa= ch. =A0The new dc is not yet ready, but while I'm waiting I was thinkin= g about updating the existing dc's replication strategy from "Simp= leStrategy" to "NetworkTopologyStrategy". =A0I also assume I= 'll need to update my snitch from the current SimpleSnitch to PropertyF= ileSnitch. =A0Here's the steps I'm thinking:

Here's a brief explication of ho= w this process works and can be made safe/testable :

http://c= assandra-user-incubator-apache-org.3065146.n2.nabble.com/Ec2Snitch-amp-Othe= r-snitches-td6196494.html

Consider whether you actually want a rack aware Snitch = :


If you do, consider using the Gossiping Property File S= nitch :


=3DRob
=A0

--089e01634dd4aa95d304f679e29d--