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 3EF6ADEB4 for ; Fri, 7 Dec 2012 17:38:02 +0000 (UTC) Received: (qmail 57202 invoked by uid 500); 7 Dec 2012 17:37:59 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 57182 invoked by uid 500); 7 Dec 2012 17:37:59 -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 57172 invoked by uid 99); 7 Dec 2012 17:37:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Dec 2012 17:37:59 +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 (athena.apache.org: domain of ailinykh@gmail.com designates 209.85.217.172 as permitted sender) Received: from [209.85.217.172] (HELO mail-lb0-f172.google.com) (209.85.217.172) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Dec 2012 17:37:54 +0000 Received: by mail-lb0-f172.google.com with SMTP id y2so671237lbk.31 for ; Fri, 07 Dec 2012 09:37:33 -0800 (PST) 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=XAxvQOpZw9WYqi/tXHVrdmb5ohfvewAhD7bV14gUeII=; b=aoJySOxtjqndyKTxZN0icqI+Y7dsUhito3kJTJ1Av7SCRDBtm724o5T8VIvcE7pcCh u1gkeUmishbnJc0BnsrDrbygOKZSgGySJRV+YRmQLYzg5bOeIOPFucPg/S6N+rH0nwQd DvjtCOI6ImpWfrPC7GM7UgrTkLwGNxhNcUwwZWZ1vS3+fuSDkny5i6nkLXMFEY7n7Np2 o3++yO5AplD2exIHzSvwtFK277i4Z8YomRrXBl6mOtTi3iWdSDu4eKt8YpXTKBf0cGq1 NaHegC2TCXIUYvSra8CZy4URQXIjxawlchl43N5IoxLdAbKeXs0jEzjn7bwuR1YFjOYg mUHQ== MIME-Version: 1.0 Received: by 10.152.148.197 with SMTP id tu5mr6179027lab.35.1354901853473; Fri, 07 Dec 2012 09:37:33 -0800 (PST) Received: by 10.114.28.34 with HTTP; Fri, 7 Dec 2012 09:37:33 -0800 (PST) In-Reply-To: References: Date: Fri, 7 Dec 2012 09:37:33 -0800 Message-ID: Subject: Re: how to take consistant snapshot? From: Andrey Ilinykh To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=e89a8f22bb53ae8b1a04d046ab68 X-Virus-Checked: Checked by ClamAV on apache.org --e89a8f22bb53ae8b1a04d046ab68 Content-Type: text/plain; charset=ISO-8859-1 That's right. But when I have incremental backup on each CF gets flushed independently. I have "hot" CF which gets flushed every several minutes and regular CF which gets flushed every hour or so. They have references to each other and data in sstables is definitely inconsistent. On Fri, Dec 7, 2012 at 9:28 AM, Tyler Hobbs wrote: > Snapshots trigger a flush first, so data that's currently in the commit > log will be covered by the snapshot. > > > On Thu, Dec 6, 2012 at 11:52 PM, Andrey Ilinykh wrote: > >> >> >> >> On Thu, Dec 6, 2012 at 7:34 PM, aaron morton wrote: >> >>> For background >>> >>> >>> http://wiki.apache.org/cassandra/Operations?highlight=%28snapshot%29#Consistent_backups >>> >>> If you it for a single node then yes there is a chance of inconsistency >>> across CF's. >>> >>> If you have mulitple nodes the snashots you take on the later nodes will >>> help. If you use CL QUOURM for reads you *may* be ok (cannot work it out >>> quickly.). If you use CL ALL for reads you will be ok. Or you can use >>> nodetool repair to ensure the data is consistent. >>> >>> I'm talking about restoring whole cluster, so all nodes are restored >> from backup and all of them are inconsistent because they lost data from >> commit logs. It doesn't matter what CL I use, some data may be lost. >> Cassandra 1.1 supports commit log archiving >> http://www.datastax.com/docs/1.1/configuration/commitlog_archiving >> I think if I store both flushed sstables and commit logs it should solve >> my problem. I'm wondering if someone has any experience with this feature? >> >> Thank you, >> Andrey >> > > > > -- > Tyler Hobbs > DataStax > > --e89a8f22bb53ae8b1a04d046ab68 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's right. But when I have incremental backup on each CF gets flushe= d independently. I have "hot" CF which gets flushed every several= minutes and regular CF which gets flushed every hour or so. They have refe= rences to each other and data in sstables is=A0definitely=A0inconsistent.


On = Fri, Dec 7, 2012 at 9:28 AM, Tyler Hobbs <tyler@datastax.com> wrote:
Snapshots trigger a flush first, so data tha= t's currently in the commit log will be covered by the snapshot.


On Thu, Dec 6, 20= 12 at 11:52 PM, Andrey Ilinykh <ailinykh@gmail.com> wrote:<= br>



On Thu, Dec 6, 2012 at 7:34 PM, aaron morton <aaron@thelastpickle.com> wrote:
For background


If you it for a single node then yes there is a chance = of inconsistency across CF's.=A0

If you have m= ulitple nodes the snashots you take on the later nodes will help. If you us= e CL QUOURM for reads you *may* be ok (cannot work it out quickly.). If you= use CL ALL for reads you will be ok. Or you can use nodetool repair to ens= ure the data is consistent.=A0

I'm talking about restorin= g whole cluster, so all nodes are restored from backup and all of them are= =A0inconsistent because they lost data =A0from commit logs. =A0It doesn'= ;t matter what CL I use, some data may be lost.=A0
Cassandra 1.1 supports commit log archiving

<= /div>



--
Tyler Hobbs
DataStax
<= br>

--e89a8f22bb53ae8b1a04d046ab68--