[CASSANDRA-2670] CF restriction not respected during repair

• Type: Bug
• Status: Resolved
• Priority: Normal
• Resolution: Duplicate
• Severity: Normal
• Assignee: Unassigned
• Reporter: Daniel Doubleday
• Created: 19/May/11 18:18
• Updated: 16/Apr/19 09:32
• Resolved: 19/May/11 18:25

Description

I see this:

• Validation compaction runs on nodes 2,3,4 for CF_A only (expected)
• Node 3 streams SSTables from CF_A only to nodes 2 and 4 (expected)
• Nodes 2 and 4 stream SSTables from ALL column families in the keyspace to node 2 (VERY unexpected)

This is a quote from:

http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Repair-on-single-CF-not-working-0-7-td5956845.html

only difference is that this description seems to be a rf=2 cluster and ours is rf=3

Seems that AES.performStreamingRepair just sends a StreamRequestMessage without CF info and the peer nodes will simply send all data from every CF in that table they have for that range. But I must be missing something since that doesn't make any sense at all.

Fact is that after minor compactions the node on which the repair was triggered basically contained everything twice.

Good news is that while our 0.6 cluster would never have survived this it almost didn't affect read latencies. That whole page cache optimization thing really seems to work. Very very cool!