Hello,

This conversation precisely targets a question that I had been having for a
while - would be grateful if you someone cloud clarify it a little further:

Considering the case of a "repair" created due to a consistency constraint
(first case in the discussion above), would the following interpretation be
correct ?

1. A digest mismatch exception is raised even if one among the many
responses (even if consistency is met on an out-of-date value, say by
virtue of timestamp).
2. A read is initiated by the callback to fetch data from all replicas
3. Resolve() is invoked to find the deltas for each replica that was out of
date.
4. ReadRepair is scheduled to the above replicas.
5. Perform a normal read and check if this meets the consistency
constraints. Mismatches would trigger a repair again.

Assuming the above is true, would the mutations in step 4 and the read in
step 5 happen in parallel ? In other words, would the time taken by the
read correction be the round trip between the coordinator and its farthest
replica that meets the consistency constraint.

Thanks,
Shankar


On Tue, Oct 23, 2012 at 3:17 AM, aaron morton <aa...@thelastpickle.com>wrote:

> Yes, all this starts because of the call to filter.collateColumns()…
>
> The ColumnFamily is an implementation of o.a.c.dbAbstractColumnContainer ,
> the methods to add columns on that interface pass through to an
> implementation of ISortedColumns.
>
> The implementations of ISortedColumns, e.g. ArrayBackedSortedColumns, will
> call reconcile() on the IColumn if they need to.
>
> Cheers
>
>   -----------------
> Aaron Morton
> Freelance Developer
> @aaronmorton
> http://www.thelastpickle.com
>
> On 23/10/2012, at 4:45 AM, Manu Zhang <owenzhang1...@gmail.com> wrote:
>
> Is it through filter.collateColumns(resolved, iters, Integer.MIN_VALUE)
> and then MergeIterator.get(toCollate, fcomp, reducer) but I don't know what
> happens hereafter? How is reconcile exactly been called?
>
> On Mon, Oct 22, 2012 at 6:49 AM, aaron morton <aa...@thelastpickle.com>wrote:
>
>> There are two processes in cassandra that trigger Read Repair like
>> behaviour.
>>
>> During a DigestMismatchException is raised if the responses from the
>> replicas do not match. In this case another read is run that involves
>> reading all the data. This is the CL level agreement kicking in.
>>
>> The other "Read Repair" is the one controlled by the
>> "read_repair_chance". When RR is active on a request ALL up replicas are
>> involved in the read. When RR is not active only CL replicas are involved.
>> When test for CL agreement occurs synchronously to the request; the RR
>> check waits asynchronously to the request for all nodes in the request to
>> return. It then checks for consistency and repairs differences.
>>
>> From looking at the source code, I do not understand how this set is
>> built and I do not understand how the reconciliation is executed.
>>
>> When a DigestMismatch is detected a read is run using RepairCallback. The
>> callback will call the RowRepairResolver.resolve() when enough responses
>> have been collected.
>>
>> resolveSuperset() picks one response to the baseline, and then calls
>> delete() to apply row level deletes from the other responses
>> (ColumnFamily's). It collects the other CF's into an iterator with a filter
>> that returns all columns. The columns are then applied to the baseline CF
>> which may result in reconcile() being called.
>>
>> reconcile() is used when a AbstractColumnContainer has two versions of a
>> column and it wants to only have one.
>>
>> RowRepairResolve.scheduleRepairs() works out the delta for each node by
>> calling ColumnFamily.diff(). The delta is then sent to the appropriate node.
>>
>>
>> Hope that helps.
>>
>>
>>   -----------------
>> Aaron Morton
>> Freelance Developer
>> @aaronmorton
>> http://www.thelastpickle.com
>>
>> On 19/10/2012, at 6:33 AM, Markus Klems <markuskl...@gmail.com> wrote:
>>
>> Hi guys,
>>
>> I am looking through the Cassandra source code in the github trunk to
>> better understand how Cassandra's fault-tolerance mechanisms work. Most
>> things make sense. I am also aware of the wiki and DataStax documentation.
>> However, I do not understand what read repair does in detail. The method
>> RowRepairResolver.resolveSuperset(Iterable<ColumnFamily> versions) seems to
>> do the trick of merging conflicting versions of column family replicas and
>> builds the set of columns that need to be "repaired". From looking at the
>> source code, I do not understand how this set is built and I do not
>> understand how the reconciliation is executed. ReadRepair does not seem to
>> trigger a Column.reconcile() to reconcile conflicting column versions on
>> different servers. Does it?
>>
>> If this is not what read repair does, then: What kind of inconsistencies
>> are resolved by read repair? And: How are the inconsistencies resolved?
>>
>> Could someone give me a hint?
>>
>> Thanks so much,
>>
>> -Markus
>>
>>
>>
>
>

Reply via email to