[
https://issues.apache.org/jira/browse/CASSANDRA-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stu Hood updated CASSANDRA-1674:
--------------------------------
Attachment: 0001-Only-repair-the-intersecting-portion-of-a-differing-ra.txt
After finding the differences for all data held on both nodes, repair was not
limiting the repaired area to the ranges that the nodes had in common. jbellis:
In your example above, because the nodes had no data in common to start with,
the MerkleTree was determining that they were different for (0,0], but rather
than intersecting the different range with the range of responsibility they had
in common, it was repairing all of (0,0].
Attaching a patch for 0.7 to only repair the intersecting ranges.
> Repair using abnormally large amounts of disk space
> ---------------------------------------------------
>
> Key: CASSANDRA-1674
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1674
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Stu Hood
> Fix For: 0.7.1
>
> Attachments:
> 0001-Only-repair-the-intersecting-portion-of-a-differing-ra.txt
>
>
> I'm watching a repair on a 7 node cluster. Repair was sent to one node; the
> node had 18G of data. No other node has more than 28G. The node where the
> repair initiated is now up to 261G with 53/60 AES tasks outstanding.
> I have seen repair take more space than expected on 0.6 but nothing this
> extreme.
> Other nodes in the cluster are occasionally logging
> WARN [ScheduledTasks:1] 2010-10-28 08:31:14,305 MessagingService.java (line
> 515) Dropped 7 messages in the last 1000ms
> The cluster is quiesced except for the repair. Not sure if the dropped
> messages are contributing the the disk space (b/c of retries?).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
