cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From A J <s5a...@gmail.com>
Subject Re: Meaning of 'nodetool repair has to run within GCGraceSeconds'
Date Mon, 11 Jul 2011 19:01:40 GMT
Never mind. I see the issue with this. I will be able to catch the
writes as failed only if I set CL=ALL. For other CLs, I may not know
that it failed on some node.

On Mon, Jul 11, 2011 at 2:33 PM, A J <s5alye@gmail.com> wrote:
> 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
>>
>

Mime
View raw message