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 2629511888 for ; Fri, 20 Jun 2014 22:52:25 +0000 (UTC) Received: (qmail 66655 invoked by uid 500); 20 Jun 2014 22:52:22 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 66614 invoked by uid 500); 20 Jun 2014 22:52:22 -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 66601 invoked by uid 99); 20 Jun 2014 22:52:22 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Jun 2014 22:52:22 +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: domain of rcoli@eventbrite.com designates 209.85.128.172 as permitted sender) Received: from [209.85.128.172] (HELO mail-ve0-f172.google.com) (209.85.128.172) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Jun 2014 22:52:18 +0000 Received: by mail-ve0-f172.google.com with SMTP id jz11so4144278veb.17 for ; Fri, 20 Jun 2014 15:51:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=EJ9xfGNqG6nnTxZwQcjfklkWgFRvL6oFSyo4rNcF4+s=; b=LS26WX17sxCMIyaSl68EmUzYrSY7jmZVlJJ1jRH9qfpY975JdHWhL3PC8cJ2/HWVkl fO9plFkzKXm2usNem5m+09RAmu2Pxju3a81yf2iZVAhL7qfYvw5fsYk+zjHmjPgPjiuK T1WTamC9fr1sJgc2xnBO010DLndAcvvA/XScKdKzdv0bSQBzft4vGkNGuAd/gXcTUHIx CJLhAPY8kSnIJ6e85z7RIeNSJ2PHQfEzZDcuiv3OAg21iDYfwVYiq+biKIHq5Q1mwR7/ KOsqe0daLh9lnVIYXN+SFmu+Cs9eTj0XfQ4x6MzegKVLGYUW7uX0oomW9jBlOSziIYVJ bfeQ== X-Gm-Message-State: ALoCoQmnxbdnFeQR2XhVSYBt/o6kylyvHpZVgmwo75FJ0kYPvunB4yuv++1KtBD+nVSXEldumofM MIME-Version: 1.0 X-Received: by 10.221.20.199 with SMTP id qp7mr5387942vcb.24.1403304713708; Fri, 20 Jun 2014 15:51:53 -0700 (PDT) Received: by 10.220.155.11 with HTTP; Fri, 20 Jun 2014 15:51:53 -0700 (PDT) In-Reply-To: References: <12D577D8-C92D-40D2-9BE2-AE98052C7606@snazy.de> Date: Fri, 20 Jun 2014 15:51:53 -0700 Message-ID: Subject: Re: Using Cassandra as cache From: Robert Coli To: "user@cassandra.apache.org" Content-Type: multipart/alternative; boundary=001a11339e2ef902b004fc4c56ac X-Virus-Checked: Checked by ClamAV on apache.org --001a11339e2ef902b004fc4c56ac Content-Type: text/plain; charset=UTF-8 On Fri, Jun 20, 2014 at 3:09 PM, DuyHai Doan wrote: > @Robert: do we still need to cleanup manually snapshot when truncating ? I remembered that on the 1.2 branch, even though the auto_snapshot param was set to false, truncating leads to snapshot creation that forced us to manually remove the snapshot folder on disk Both DROP and TRUNCATE auto_snapshot by default, yes. > Can you please explain what problems DROP/CREATE keyspace may cause? Check JIRA, but in general currently DROP/CREATE same entity can cause bugs. DROP/CREATE with always unique names should be fine. > Seems like truncate working per column family and I have up to 10. So TRUNCATE all 10? > Can working RF=2 and CL=ANY result in any problem with consistency? I am not sure I can have problems with consistency if I don't do updates, only writes and reads. Can I? CL=ANY is a problem with consistency. Wherever you read the instruction to consider ever using it for any reason, strongly consider never visiting that site again. RF=2 means you can't use QUORUM without using CL.ALL. Not being able to use QUORUM can result in consistency problems. Using CL.ALL results in availability problems. =Rob --001a11339e2ef902b004fc4c56ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 20, 2014 at 3:09 PM, DuyHai Doan <doanduyhai@gmail.com><= /span> wrote:
> @Robert: do we still need to cleanup manual= ly snapshot when truncating ? I remembered that on the 1.2 branch, even tho= ugh the auto_snapshot param was set to false, truncating leads to snapshot = creation that forced us to manually remove the snapshot folder on disk

Both DROP and TRUNCATE auto_snapshot by default, yes.
<= div>
>=C2=A0Can you please explain what problems DROP/CREATE keyspace may= cause?

Che= ck JIRA, but in general currently DROP/CREATE same entity can cause bugs. D= ROP/CREATE with always unique names should be fine.

>=C2=A0Seems like truncate working per column family and I have up = to 10.

So TRUNCATE all 10?

>=C2=A0Can working RF=3D2 and CL=3DANY result in= any problem with consistency? I am not sure I can have problems with consi= stency if I don't do updates, only writes and reads. Can I?

CL= =3DANY is a problem with consistency. Wherever you read the instruction to = consider ever using it for any reason, strongly consider never visiting tha= t site again.

RF= =3D2 means you can't use QUORUM without using CL.ALL. Not being able to= use QUORUM can result in consistency problems. Using CL.ALL results in ava= ilability problems.

=3DRob
=C2=A0
--001a11339e2ef902b004fc4c56ac--