From user-return-38185-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Mon Dec 23 17:43:23 2013 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 2A42910810 for ; Mon, 23 Dec 2013 17:43:23 +0000 (UTC) Received: (qmail 16913 invoked by uid 500); 23 Dec 2013 17:43:19 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 16538 invoked by uid 500); 23 Dec 2013 17:43:15 -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 16529 invoked by uid 99); 23 Dec 2013 17:43:14 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Dec 2013 17:43:14 +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 (nike.apache.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [209.85.160.50] (HELO mail-pb0-f50.google.com) (209.85.160.50) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Dec 2013 17:43:08 +0000 Received: by mail-pb0-f50.google.com with SMTP id rr13so5525730pbb.37 for ; Mon, 23 Dec 2013 09:42:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to; bh=CIK5z1zyxUnlXAp2uDulH64YdlY2X5yb3i7PkIZ17Y8=; b=ZayoHr4lQCMX2KsoR2yk2PZUr1NK4KMmGnIvyS1o9Mo2R0uaRxEq+q3e8FJ9psYsIc wGIk5bqhpeF3n69gZg9QfTK6tYgyejzsPzIwcYZekt5ysCTEXK4t0Vg6CS2a6vf3MIeW L4k2RzPLEAGbyWuQfUARiu0Hn5WMys51MRj9FPq/FsrwoLJtHhtfy3o+6X7VqkQ7qxXf sQ1nrO4gXv1u+/EuEvFP/87bo0YcVls0ObpXIKUNdlp8eASq9ICAsClvQoNTrpSBoB6t Z2X4x8rvQ4ujLZTdmtupPJOI43W1yIu+jm0KqES45wp1TxNxFPDB2d+zX773qs9Q5RhC U2cw== X-Gm-Message-State: ALoCoQmAZCC/rc3KfuaN4b/IO4+TIsabOK68vySWLloOXORfcB2KFKp6DErn5ixDTLoBUC7+FHUq X-Received: by 10.68.108.194 with SMTP id hm2mr27616648pbb.22.1387820566517; Mon, 23 Dec 2013 09:42:46 -0800 (PST) Received: from [172.16.1.18] ([203.86.207.101]) by mx.google.com with ESMTPSA id i10sm46754675pat.11.2013.12.23.09.42.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Dec 2013 09:42:45 -0800 (PST) From: Aaron Morton Content-Type: multipart/alternative; boundary="Apple-Mail=_677BB31A-A5B3-4C84-82CB-BDA12726089F" Message-Id: <27293F39-6CCD-4F57-87D8-B4034C73F35E@thelastpickle.com> Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Writes during schema migration Date: Tue, 24 Dec 2013 06:42:44 +1300 References: To: Cassandra User In-Reply-To: X-Mailer: Apple Mail (2.1827) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_677BB31A-A5B3-4C84-82CB-BDA12726089F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 It depends a little on the nature of the change, but you need some = coordination between the schema change and your code. e.g. add new = column, change code to write to it or add new column, change code to use = new column and not old column, remove old column.=20 Cheers ----------------- Aaron Morton New Zealand @aaronmorton Co-Founder & Principal Consultant Apache Cassandra Consulting http://www.thelastpickle.com On 19/12/2013, at 3:02 am, Ben Hood <0x6e6562@gmail.com> wrote: > Hi, >=20 > I was wondering if anybody knows any best practices of how to apply a > schema migration across a cluster. >=20 > I've been reading this article: >=20 > http://www.datastax.com/dev/blog/the-schema-management-renaissance >=20 > to see what is happening under the covers. However the article doesn't > seem to talk about concurrent write access during the migration > process. >=20 > I'm naively assuming that you'd need to block all writes to the > cluster before the migration is started. This is would be firstly > because of potential consistency issues amongst the cluster nodes. But > this would also be because you'd need two versions of your app to > running at the same time. >=20 > Does anybody have any experience with doing this kind of thing? >=20 > Cheers, >=20 > Ben --Apple-Mail=_677BB31A-A5B3-4C84-82CB-BDA12726089F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 It = depends a little on the nature of the change, but you need some = coordination between the schema change and your code. e.g. add new = column, change code to write to it or add new column, change code to use = new column and not old column, remove old = column. 

Cheers

http://www.thelastpickle.com

On 19/12/2013, at 3:02 am, Ben Hood <0x6e6562@gmail.com> = wrote:

Hi,

I was wondering if anybody knows any best = practices of how to apply a
schema migration across a = cluster.

I've been reading this article:

http://www.datastax.com/dev/blog/the-schema-management-renaissance
to see what is happening under the covers. However the article = doesn't
seem to talk about concurrent write access during the = migration
process.

I'm naively assuming that you'd need to = block all writes to the
cluster before the migration is started. This = is would be firstly
because of potential consistency issues amongst = the cluster nodes. But
this would also be because you'd need two = versions of your app to
running at the same time.

Does anybody = have any experience with doing this kind of = thing?

Cheers,

Ben

= --Apple-Mail=_677BB31A-A5B3-4C84-82CB-BDA12726089F--