cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jun Rao (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-193) Proactive repair
Date Mon, 09 Nov 2009 20:06:34 GMT


Jun Rao commented on CASSANDRA-193:

Started reviewing this patch. Here is a high-level question. From the code, the process roughly
looks as the follows:
1. Each node N periodically computes a Merkle tree for rows in each new SSTable generated
through compaction.
2. The Merkle tree is sent and registered to other nodes that share key ranges with N.
3. The locally computed Merkle tree will be compared with those registered remote Merkle trees.
If there is any difference, trigger a repair.

Since compaction is triggered independently at each node, the rows in two compacted SSTables
generated in two neighboring nodes are unlikely to match. Won't the above approach trigger
too many unnecessary repairs?

> Proactive repair
> ----------------
>                 Key: CASSANDRA-193
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Stu Hood
>             Fix For: 0.5
>         Attachments: 193-1-tree-preparation.diff, 193-2-tree.diff, 193-3-aes-preparation.diff,
> Currently cassandra supports "read repair," i.e., lazy repair when a read is done.  This
is better than nothing but is not sufficient for some cases (e.g. catastrophic node failure
where you need to rebuild all of a node's data on a new machine).
> Dynamo uses merkle trees here.  This is harder for Cassandra given the CF data model
but I suppose we could just hash the serialized CF value.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message