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 8F172F9BA for ; Tue, 23 Apr 2013 07:27:40 +0000 (UTC) Received: (qmail 51164 invoked by uid 500); 23 Apr 2013 07:27:38 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 50771 invoked by uid 500); 23 Apr 2013 07:27:37 -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 50757 invoked by uid 99); 23 Apr 2013 07:27:37 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Apr 2013 07:27:37 +0000 X-ASF-Spam-Status: No, hits=2.8 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,URI_HEX X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of arodrime@gmail.com designates 209.85.217.176 as permitted sender) Received: from [209.85.217.176] (HELO mail-lb0-f176.google.com) (209.85.217.176) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Apr 2013 07:27:31 +0000 Received: by mail-lb0-f176.google.com with SMTP id y8so352286lbh.7 for ; Tue, 23 Apr 2013 00:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=UU5epXwVd+Qsq6NnvSEUhCYr+Kt4apKrZC5vQBSLxNE=; b=Lph3xEGX2mx6xvX7f3Qm/huxSsVnxko+SM85JR1YMOq3dfIe8acYSYx8/OLIKCtW3e YwK5AHA9aVvFRGM8CoB7jQOREVtc0CpUWOJhqGa316MF9MU73+I/qV0N0MxQU1y3h04z wNzAWjlfpl25idj58clyyN3ukp+RGYl72PLjms6cw30T5lxGcELj8qLFZAQ0qfVtjfK5 kIewbDFAHZFcUEmVvdfM1T8VAgyeGEoQ8M3A9Gc2wGjS4N1Kd4nZ1Dw/EIY1J7Jpt12v JtEfZMfjSraAp7QLYN1H4DBoY7AwdnREJcCOU0Y/P3fwehmjqHawJGu0I2cr6GK4TuRr sZfw== X-Received: by 10.112.20.133 with SMTP id n5mr14471239lbe.113.1366702031020; Tue, 23 Apr 2013 00:27:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.168.1 with HTTP; Tue, 23 Apr 2013 00:26:49 -0700 (PDT) In-Reply-To: References: From: Alain RODRIGUEZ Date: Tue, 23 Apr 2013 09:26:49 +0200 Message-ID: Subject: Re: Ec2Snitch to Ec2MultiRegionSnitch To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=14dae94732d312a86604db021d5d X-Virus-Checked: Checked by ClamAV on apache.org --14dae94732d312a86604db021d5d Content-Type: text/plain; charset=ISO-8859-1 Hi,these advice are very welcome. @Dane, about the rack awareness, we use only one rack per DC, so I guess using EC2MultiRegionSnitch will do just fine and it doesn't need any configuration. Does it seem right to you. If we are someday interested on multi racks I will make sure to use them properly. Thank you for this insight anyway. You are advising me to test it, what would be a good way of testing it (I can use AWS EC2 instances if needed) ? @Aaron "I recommend using the same number of nodes in both DC's." Why ? I mean we have maybe only 5% of our customers on the us-east zone, what in C* require to have the same number of node on each DC ? "Add the nodes (I recommend 6) with auto_bootstrap: false added to the yaml. update the keyspace replication strategy to add rf:3 for the new DC. Use nodetool rebuild on the new nodes to rebuild them from the us-west DC. " What is better on adding nodes with no data and then rebuild them compared to using the auto_bootstrap ? "I prefer to use the offset method. Take the 6 tokens from your us-west DC and add 100 to them for the new dc. " Any doc on this ? I am not aware of all the possibilities. Why is this the best method according to you ? About seeds => "Yes. Have 3 from each." What is the point of this ? I didn't thought this change would be that tricky, thank you guys for these warnings and your help ;) Alain 2013/4/23 Dane Miller > On Thu, Apr 18, 2013 at 7:41 AM, Alain RODRIGUEZ > wrote: > > I am wondering about the process to grow from one data center to a few of > > them. First thing is we use EC2Snitch for now. So I guess we have to > switch > > to Ec2MultiRegionSnitch. > > > > c/ I am using the SimpleStrategy. Is it worth it/mandatory to change this > > strategy when using multiple DC ? > > I suggest you thoroughly read the datastax documentation on cassandra > replication. The change you are planning is big - make sure to try it > in a test environment first. Also, you might find you don't really > need Cassandra's rack aware feature, and can operate using > (Gossiping)PropertyFileSnitch. The rack feature is listed as an > "anti-pattern" here: > http://www.datastax.com/docs/1.2/cluster_architecture/anti_patterns > > Here are some recent discussions on this list: > > http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/migrating-from-SimpleStrategy-to-NetworkTopologyStrategy-tp7586272.html > > http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/migrating-from-SimpleStrategy-to-NetworkTopologyStrategy-tp7481090.html > > Dane > --14dae94732d312a86604db021d5d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,these advice are very welcome.

@Dane, about the rack awareness, we use only one rack per DC, so I guess u= sing EC2MultiRegionSnitch will do just fine and it doesn't need any con= figuration. Does it seem right to you. If we are someday interested on mult= i racks I will make sure to use them properly. Thank you for this insight a= nyway. You are advising me to test it, what would be a good way of testing = it (I can use AWS EC2 instances if needed) ?

@Aaron

"I recomm= end using the same number of nodes in both DC's."

=
Why ? I mean we have maybe only 5% of our customers on the us-east= zone, what in C* require to have the same number of node on each DC ?

"Add the nodes (I recommend 6) with auto_bootstrap: fa= lse added to the yaml.
update the keyspace replication strategy to add rf:3 for the new DC.=A0
Use nodetool r= ebuild on the new nodes to rebuild them from the us-west DC. "

What i= s better on adding nodes with no data and then rebuild them compared to usi= ng the auto_bootstrap ?

"= I prefer to use the offset method. Take the 6 tokens from your us-west DC a= nd add 100 to them for the new dc. "

Any do= c on this ? I am not aware of all the possibilities. Why is this the best m= ethod according to you ?
<= /tbody>
<= div class=3D"" tabindex=3D"-1">
=

=
About seeds =3D> "Yes. Have 3 from each= ."

What is the point of this ?

I didn't thought this cha= nge would be that tricky, thank you guys for these warnings and your help ;= )

Alain


2013/4/23 Dane Miller <dane@optimalsocial.com>
On Thu, Apr 18, 2013 at 7:41 AM, Alain RODRIGUEZ <arodrime@gmail.com> wrote:
> I am wondering about the process to grow from one data center to a few= of
> them. First thing is we use EC2Snitch for now. So I guess we have to s= witch
> to Ec2MultiRegionSnitch.
>
> c/ I am using the SimpleStrategy. Is it worth = it/mandatory to change this
> strategy when using multiple DC ?

I suggest you thoroughly read the datastax documentation on cassandra=
replication. =A0The change you are planning is big - make sure to try it in a test environment first. =A0Also, you might find you don't really need Cassandra's rack aware feature, and can operate using
(Gossiping)PropertyFileSnitch. =A0The rack feature is listed as an
"anti-pattern" here:
http://www.datastax.com/docs/1.2/cluster_architectur= e/anti_patterns

Here are some recent discussions on this list:
http://cassandra-user-incubator-apache-org.3065146.n2.nabb= le.com/migrating-from-SimpleStrategy-to-NetworkTopologyStrategy-tp7586272.h= tml
http://cassandra-user-incubator-apache-org.3065146.n2.nabb= le.com/migrating-from-SimpleStrategy-to-NetworkTopologyStrategy-tp7481090.h= tml

Dane

--14dae94732d312a86604db021d5d--