From user-return-61841-archive-asf-public=cust-asf.ponee.io@cassandra.apache.org Thu Aug 2 03:47:54 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 04A97180634 for ; Thu, 2 Aug 2018 03:47:53 +0200 (CEST) Received: (qmail 97529 invoked by uid 500); 2 Aug 2018 01:47:52 -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 97519 invoked by uid 99); 2 Aug 2018 01:47:52 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Aug 2018 01:47:52 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 106351A35EA for ; Thu, 2 Aug 2018 01:47:52 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.87 X-Spam-Level: * X-Spam-Status: No, score=1.87 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id iiNII04RCccY for ; Thu, 2 Aug 2018 01:47:50 +0000 (UTC) Received: from mail-pl0-f68.google.com (mail-pl0-f68.google.com [209.85.160.68]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id C623C5F27B for ; Thu, 2 Aug 2018 01:47:49 +0000 (UTC) Received: by mail-pl0-f68.google.com with SMTP id t17-v6so251558ply.13 for ; Wed, 01 Aug 2018 18:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :references:in-reply-to:to; bh=c0HERPGAbMxMZlmT0w4Ca5/jFf8PmIvpaD6iqJKoqXo=; b=fgds9OLAt1aNAskDHgUZXI2USI1xf3D9qUUNeTCxcEfAO5OJ6HEWOO0mruW4XBivs5 rJrl9bl/dQi9/lEs4HTtX/hcDHvgRudRkpI6yb3H3D30GodvB0CixNOHde+089oESd9w KxgsRht3HW0f1zfPnO/sxsQe/rs4STzJMSCJdE1yoLJHgDd7J+Khq5PYaBlfFX2EsxyW jNEFjB63EktKswcTItb2d9autXBqUdvdbE13J8d9beUgGMZAyYhTnWZQThb23u/U+bP+ r3WEFRZIJIWg4uXn4Mpt3XOQ9VT1LFYlO8KoZwp5/Jnohxxxh7yYCLXYK951jZUaqjMi SvdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:references:in-reply-to:to; bh=c0HERPGAbMxMZlmT0w4Ca5/jFf8PmIvpaD6iqJKoqXo=; b=jJrg7NY+0K8m8NbVXGP+ck/7Ggjul+N8p48xeePQ37mfC/zmyJImeteRiXbKB5mBRR ltnVd8e99EvvqJ/c+xJFH9O3SUuYz36MYmV5/NlVVqG6gkKRy538fbe5xx0LBljDh0H0 V+r36GPrW8CckrCBVvgU6WAJe4Esl3DPmE0EG07C2li1l0QbyWD7Bi2CeznkQfw8a1nZ tLLcFhlDEwfva6eNf3gdpulIOOvLlTa93ZT5c4ipJXoyczfR5uYKmLv+xTkJ90UDbtyC iVTLfSDezVGTpsHtvXENr1cD3BfLqTBhTxHO08LBuXtQT7xIl2b7HFKWXMCsH1oJ34wg lxWA== X-Gm-Message-State: AOUpUlGYbThJKiVG+BM9FWnMYNUbgt/6e8Y/L+1Lyr9LRuqWtN9XfFyI tqGpEqmZZ1KyMe1NZau88HSzGamm X-Google-Smtp-Source: AAOMgpeZiYmCelGLHiow0U/aXnQcbp6d5n2KBs3bvOPBZnd2gOVQpopp0qCe2TRrRzUBpwAlGXs/wA== X-Received: by 2002:a17:902:d218:: with SMTP id t24-v6mr607165ply.63.1533174468227; Wed, 01 Aug 2018 18:47:48 -0700 (PDT) Received: from ?IPv6:2600:380:8037:6898:a093:631d:d4e6:f551? ([2600:380:8037:6898:a093:631d:d4e6:f551]) by smtp.gmail.com with ESMTPSA id j27-v6sm521219pfj.91.2018.08.01.18.47.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Aug 2018 18:47:47 -0700 (PDT) From: Jeff Jirsa Content-Type: multipart/alternative; boundary=Apple-Mail-2975D7A8-9349-4770-B19A-78CAD4CF45BB Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Wed, 1 Aug 2018 18:47:46 -0700 Subject: Re: Alter table Message-Id: References: <6ED256DC-9237-436B-BCB8-9BF0A5E01452@gmail.com> <4C5639FC-E336-4E41-A640-19A0514E87FC@gmail.com> In-Reply-To: <4C5639FC-E336-4E41-A640-19A0514E87FC@gmail.com> To: user@cassandra.apache.org X-Mailer: iPhone Mail (15G77) --Apple-Mail-2975D7A8-9349-4770-B19A-78CAD4CF45BB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable (My advice stands, I still believe it to be safe in all modern versions not i= mpacted by 13004, but) There=E2=80=99s little difference between adding columns and removing column= s - if you=E2=80=99re afraid of writes while you add columns, you should be a= fraid of writes while you remove columns. (But I don=E2=80=99t think you should be afraid of either) --=20 Jeff Jirsa > On Aug 1, 2018, at 6:43 PM, Visa wrote: >=20 > Thanks for all the inputs! We=E2=80=99ll stick to the current approach the= n. >=20 > How about dropping columns - If we also stop writes beforehand, we should b= e safe from data alignment issue after dropping columns? >=20 > Thanks, > Li >=20 >> On Jul 31, 2018, at 04:14, James Shaw wrote: >>=20 >> in a heavy transaction PROD env, it is risk, considering c* has a lot of b= ugs. >> the DDL has to be replicated to all nodes, use nodetool describecluster t= o check schema version same on all nodes, if not, you may restart that node= which DDL not replicated. >> in new version, DDL is none or all, you may not get it success. >>=20 >> It is similar to rdbms, alter table in a heavy transaction PROD env, may= get resource busy error. >>=20 >> in non-prod, we always apply new DDL without stop applications, never had= issue. >>=20 >> Thanks, >>=20 >> James >>=20 >>=20 >>> On Tue, Jul 31, 2018 at 1:37 AM, Jeff Jirsa wrote: >>> This is safe (and normal, and good) in all versions except those impacte= d by https://issues.apache.org/jira/browse/CASSANDRA-13004=20 >>>=20 >>> So if you're on 2.1, 2.2, or 3.11 you're fine >>>=20 >>> If you're on 3.0 between 3.0.0 and 3.0.13, you should upgrade first (to n= ewest 3.0, probably 3.0.17) >>> If you're on a version between 3.1 and 3.10, you should upgrade first (t= o newest 3.11, probably 3.11.3) >>>=20 >>> - Jeff >>>=20 >>>=20 >>>> On Mon, Jul 30, 2018 at 10:16 PM, Visa wrote: >>>> Hi all, >>>>=20 >>>> I have one question about altering schema. If we only add columns, is i= t ok to alter the schema while the writes to the table are happening at the s= ame time? We can control that the writes will not touch the new columns unti= l the schema change is done. Or better to stop the writes to that table firs= t. >>>>=20 >>>> Thanks! >>>>=20 >>>> Li >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: user-unsubscribe@cassandra.apache.org >>>> For additional commands, e-mail: user-help@cassandra.apache.org >>>>=20 >>>=20 >>=20 --Apple-Mail-2975D7A8-9349-4770-B19A-78CAD4CF45BB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable (My advice stands, I still believe it to be= safe in all modern versions not impacted by 13004, but)

= There=E2=80=99s little difference between adding columns and removing column= s - if you=E2=80=99re afraid of writes while you add columns, you should be a= fraid of writes while you remove columns.

(But I do= n=E2=80=99t think you should be afraid of either)

-- 
Jeff Jirsa


On Au= g 1, 2018, at 6:43 PM, Visa <li= guilin2015@gmail.com> wrote:

<= div>Thanks for all the inputs! We=E2=80=99ll stick to the current approach then= .

How about dropping columns - If we also stop writes bef= orehand, we should be safe from data alignment issue after dropping columns?=

Thanks,
Li

On Jul 31, 2018, at 0= 4:14, James Shaw <jxyshaw@gmail.com<= /a>> wrote:

=
in a heavy transaction PROD env, it is risk, considering c* has a lot o= f bugs.
the DDL has to be replicated to all nodes,  use nodet= ool describecluster to check schema version same on all nodes, if not, = you may restart that node which DDL not replicated.
in new versio= n, DDL is none or all,  you may not get it success.

It is similar to rdbms,  alter table in a heavy transaction PROD e= nv, may get resource busy error.

in non-prod, we al= ways apply new DDL without stop applications, never had issue.
Thanks,

James


On Tue, Jul 31, 2018 at 1= :37 AM, Jeff Jirsa <jjirsa@gmail.com> wrote:
This is safe (and normal, and good) in all v= ersions except those impacted by https://issues.apache.org/jira/browse/CASSANDRA-13004 

So if you're on 2.= 1, 2.2, or 3.11 you're fine

If you're on 3.0 betwee= n 3.0.0 and 3.0.13, you should upgrade first (to newest 3.0, probably 3.0.17= )
If you're on a version between 3.1 and 3.10, you should upgrade f= irst (to newest 3.11, probably 3.11.3)

- Jeff

=
On Mon, Jul 30, 2018 at 10:16 PM, Visa <lig= uilin2015@gmail.com> wrote:
H= i all,

I have one question about altering schema. If we only add columns, is it ok t= o alter the schema while the writes to the table are happening at the same t= ime? We can control that the writes will not touch the new columns until the= schema change is done. Or better to stop the writes to that table first.
Thanks!

Li
------------------------------------------------------------------= ---
To unsubscribe, e-mail: user-unsubscribe@cassandra.apache.org
For additional commands, e-mail: user-help@cassandra.apache.org



= --Apple-Mail-2975D7A8-9349-4770-B19A-78CAD4CF45BB--