Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (nike.apache.org: domain of s5alye@gmail.com designates
 209.85.214.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <BANLkTik98gYBMeBxBUVovA91LGq+fJQtLA@mail.gmail.com>
References: <BANLkTik4HynV=GnzMi3n8OAa20HFSzej5g@mail.gmail.com>
	<BANLkTindb2CrWaQeRp9NFGnu9FZk2-svug@mail.gmail.com>
	<BANLkTik98gYBMeBxBUVovA91LGq+fJQtLA@mail.gmail.com>
Date: Mon, 11 Jul 2011 14:33:50 -0400
Message-ID: 
 <CAGXoe2XOFNGOddwFYgQ0FeZY5NFYs-KmtbSoD7=RZaP2j_65-g@mail.gmail.com>
Subject: Re: Meaning of 'nodetool repair has to run within GCGraceSeconds'
From: A J <s5alye@gmail.com>
To: user@cassandra.apache.org
Content-Type: text/plain; charset=ISO-8859-1

Instead of doing nodetool repair, is it not a cheaper operation to
keep tab of failed writes (be it deletes or inserts or updates) and
read these failed writes at a set frequency in some batch job ? By
reading them, RR would get triggered and they would get to a
consistent state.

Because these would targeted reads (only for those that failed during
writes), it should be a shorter list and quick to repair (than
nodetool repair).


On Thu, Jun 30, 2011 at 5:27 PM, Jonathan Ellis <jbellis@gmail.com> wrote:
> On Thu, Jun 30, 2011 at 3:47 PM, Edward Capriolo <edlinuxguru@gmail.com> wrote:
>> Read repair does NOT repair tombstones.
>
> It does, but you can't rely on RR to repair _all_ tombstones, because
> RR only happens if the row in question is requested by a client.
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of DataStax, the source for professional Cassandra support
> http://www.datastax.com
>