cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Jirsa <jji...@gmail.com>
Subject Re: What really happened during repair?
Date Sun, 04 Aug 2019 00:29:06 GMT

> On Aug 3, 2019, at 5:03 PM, Martin Xue <martinxue@gmail.com> wrote:
> 
> Hi Cassandra community,
> 
> I am using Cassandra 3.0.14, 1 cluster, node a,b,c in DC1, node d,e,f in DC2. 
> 
> Keyspace_m is 1TB
> 
> When I run repair -pr a full keyspace_m on node a, what I noticed are:
> 1. Repair process is running on node a
> 2. Anti compaction after repair are running on other nodes at least node b,d,e,f
> 
> I want to know 
> 1. why there are anti compactions running after repair?


They should run before repair - they split data you’re going to repair from data you’re
not going to repair

If they’re running after, either there’s another repair command on adjacent nodes or you’re
repairing multiple key spaces and lost track

> 2. Why it needs to run on other nodes? (I only run primary range repair on node a)

Every host involved in the repair will anticompact to split data in the range you’re repairing
from other data. That means RF number of hosts  will run anticompaction for each range you
repair 
> 3. What's the purpose of anti compaction after repair?

Answered above , but reminder it’s before 

> 4. Can I disable the anti compaction? If so any damage will cause? (It takes more than
2 days to run on 1TB keyspace_m, and filled up disk quickly, too time and resources consuming)


You can run full repair instead of incremental by passing -full

But he cost of anticompaction should go down after the first successful incremental repair

> 
> Any suggestions would be appreciated.
> 
> Thanks
> Regards
> Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@cassandra.apache.org
For additional commands, e-mail: user-help@cassandra.apache.org


Mime
View raw message