cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Podkowinski (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-13489) Cassandra Repair in 2.2.8
Date Thu, 04 May 2017 07:50:04 GMT


Stefan Podkowinski commented on CASSANDRA-13489:

Can you either describe how this is a bug or how you'd suggest to change the described behavior?

Open questions and discussions on how to organize and tune repairs belong to the community
channels, such as the users mailing list.

> Cassandra Repair in 2.2.8
> -------------------------
>                 Key: CASSANDRA-13489
>                 URL:
>             Project: Cassandra
>          Issue Type: Task
>         Environment: Linux Redhat Enterprise, 32 GB RAM, 
>            Reporter: Shoban
>            Priority: Critical
> I am using 4 node, 2 data center Cassandra cluster. While running nodetool repair -dcpar
it takes arund 2 hours 30 minutes for database size of 20 MB. I checked how to tune streaming
of data between data centers from below url:
> But still the repair takes 2 hours and 30 mins. I drilled down the repair logs and identified
while repair Cassandra repairs 256 ranges per node which is 4*256=1024. In a single token
range merkle tree for each column families is compared which takes around 110 ms. We have
80 column families thus it takes 110*80*1024 which results in 2 hours 30 mins.
> Can we reduce number of traffic by generating merkle tree for more than one column family
at a time? 
> Or is there any other way to reduce the repair procedure in Cassandra 2.2.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message