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 5EECBD97C for ; Mon, 1 Oct 2012 18:57:26 +0000 (UTC) Received: (qmail 58060 invoked by uid 500); 1 Oct 2012 18:57:24 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 57981 invoked by uid 500); 1 Oct 2012 18:57:24 -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 57973 invoked by uid 99); 1 Oct 2012 18:57:24 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Oct 2012 18:57:24 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of synfinatic@gmail.com designates 209.85.214.172 as permitted sender) Received: from [209.85.214.172] (HELO mail-ob0-f172.google.com) (209.85.214.172) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Oct 2012 18:57:18 +0000 Received: by obqv19 with SMTP id v19so6450052obq.31 for ; Mon, 01 Oct 2012 11:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=yCZDMBqdQHvYJLg+0H697x6//8upZ3xmHsEAixPIpnA=; b=mONlen8xHWao8S7i/hrg4vf6dqqfWJ7JcGXDzc7Ic31nlmnXu2Z/x+EStz9JxrBPtl 9p4dwFbz2N26wiw7f6JjlGgWBO/lvxzbqZWXAIoaEwYAbEIjQBUNQwDiqPjD+Ol2Ifi8 S3BXkPiBj/F0zsViZpXkVEti20Cu0MzdSiLkyG5Dj9MFwIWTge5MikpTaDM9i8l5oGXG AzBQOB8NEGKLz3lWOevhoabmCZ9nv1in98R1xFm1aXODZkT6Y+tVS+uYkpcYmxcm2kJ/ GTcT5mynEbJnmQ/phtmfiWdwcwWRhGO2kS+iVyocJ4tVFi2tB9tzAG4srJtcyAIWcQHA oHVg== Received: by 10.60.24.69 with SMTP id s5mr12701850oef.45.1349117817304; Mon, 01 Oct 2012 11:56:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.42.166 with HTTP; Mon, 1 Oct 2012 11:56:37 -0700 (PDT) In-Reply-To: References: From: Aaron Turner Date: Mon, 1 Oct 2012 19:56:37 +0100 Message-ID: Subject: Re: read-repair and deletes / forgotten deletes To: user@cassandra.apache.org Content-Type: text/plain; charset=ISO-8859-1 inline... On Mon, Oct 1, 2012 at 7:46 PM, Hiller, Dean wrote: > Thanks, (actually new it was configurable) BUT what I don't get is why I > have to run a repair. IF all nodes became consistent on the delete, it > should not be possible to get a forgotten delete, correct. The forgotten > delete will only occur if I have a node down and out for 10 days and it > comes back online because by then the nodes no longer have the delete > anymore and the new node has data so getting to a consistent state the > node with data would win. > > Soooo, if I run repair say every 20 days, isn't it true, I would have no > problems as long as I did not have a node outage? Basically if you know for certain that you have 100% uptime for all your nodes and you haven't lost any updates due to overload/etc then you don't need to run repair. You run repair to ensure that all the tombstones are replicated to all the necessary nodes prior to gc_grace so that the data doesn't come back from the dead after a compaction. Generally speaking it's a lot safer/easier to just always run repair. > And most importantly, does anyone know of an automated tool for running > repairs every X days(this should really be an automated/schedulable > thing)??? I use a cron job. It's a good idea to use the '-pr' flag btw. Also, you only need to run repair against CF's which actually have deletes. -- Aaron Turner http://synfin.net/ Twitter: @synfinatic http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin "carpe diem quam minimum credula postero"