Re: nodetool repair taking forever

2012-05-25 Thread Raj N
Thanks for the reply Aaron. By compaction being on, do you mean if run
nodetool compact, then the answer is no. I haven't set any explicit
compaction_thresholds which means it should be using the default, min 4 and
max 32. Having said that to solve the problem, I just did a full cluster
restart and ran nodetool repair again. The entire cluster of 6 nodes was
repaired in 10 hours. I am also contemplating since all the 6 nodes are
replicas of each other, do I even need to run repair on all the nodes.
Wouldn't running it on the first node suffice since it will repair all the
ranges its responsible for(which is everything). So unless I upgrade to
1.0.+, where I can use the -pr option is it advisable to just run repair on
the first node.

-Raj

On Tue, May 22, 2012 at 5:05 AM, aaron morton aa...@thelastpickle.comwrote:

 I also dont understand if all these nodes are replicas of each other why
 is that the first node has almost double the data.

 Have you performed any token moves ? Old data is not deleted unless you
 run nodetool cleanup.
 Another possibility is things like a lot of hints. Admittedly it would
 have to be a *lot* of hints.
 The third is that compaction has fallen behind.

 This week its even worse, the nodetool repair has been running for the
 last 15 hours just on the first node and when I run nodetool
 compactionstats I constantly see this -

 pending tasks: 3

 First check the logs for errors.

 Repair will first calculate the differences, you can see this as a
 validation compaction in nodetool compactionstats.
 Then it will stream the data, you can watch that with nodetool netstats.

 Try to work out which part is taking the most time.   15 hours for 50Gb
 sounds like a long time (btw do you have compaction on ?)

 Cheers

 -
 Aaron Morton
 Freelance Developer
 @aaronmorton
 http://www.thelastpickle.com

 On 20/05/2012, at 3:14 AM, Raj N wrote:

 Hi experts,

 I have a 6 node cluster spread across 2 DCs.

 DC  RackStatus State   LoadOwnsToken

  113427455640312814857969558651062452225
 DC1 RAC13   Up Normal  95.98 GB33.33%  0
 DC2 RAC5Up Normal  50.79 GB0.00%   1
 DC1 RAC18   Up Normal  50.83 GB33.33%
  56713727820156407428984779325531226112
 DC2 RAC7Up Normal  50.74 GB0.00%
 56713727820156407428984779325531226113
 DC1 RAC19   Up Normal  61.72 GB33.33%
  113427455640312814857969558651062452224
 DC2 RAC9Up Normal  50.83 GB0.00%
 113427455640312814857969558651062452225

 They are all replicas of each other. All reads and writes are done at
 LOCAL_QUORUM. We are on Cassandra 0.8.4. I see that our weekend nodetool
 repair runs for more than 12 hours. Especially on the first one which has
 96 GB data. Is this usual? We are using 500 GB SAS drives with ext4 file
 system. This gets worse every week. This week its even worse, the nodetool
 repair has been running for the last 15 hours just on the first node and
 when I run nodetool compactionstats I constantly see this -

 pending tasks: 3

 and nothing else. Looks like its just stuck. There's nothing substantial
 in the logs as well. I also dont understand if all these nodes are replicas
 of each other why is that the first node has almost double the data. Any
 help will be really appreciated.

 Thanks
 -Raj





Re: nodetool repair taking forever

2012-05-25 Thread Rob Coli
On Sat, May 19, 2012 at 8:14 AM, Raj N raj.cassan...@gmail.com wrote:
 Hi experts,
 [ repair seems to be hanging forever ]

https://issues.apache.org/jira/browse/CASSANDRA-2433

Affects 0.8.4.

I also believe there is a contemporaneous bug (reported by Stu Hood?)
regarding failed repair resulting in extra disk usage, but I can't
currently find it in JIRA.

=Rob

-- 
=Robert Coli
AIMGTALK - rc...@palominodb.com
YAHOO - rcoli.palominob
SKYPE - rcoli_palominodb


Re: nodetool repair taking forever

2012-05-22 Thread aaron morton
 I also dont understand if all these nodes are replicas of each other why is 
 that the first node has almost double the data.
Have you performed any token moves ? Old data is not deleted unless you run 
nodetool cleanup. 
Another possibility is things like a lot of hints. Admittedly it would have to 
be a *lot* of hints.
The third is that compaction has fallen behind. 

 This week its even worse, the nodetool repair has been running for the last 
 15 hours just on the first node and when I run nodetool compactionstats I 
 constantly see this -
 
 pending tasks: 3
First check the logs for errors. 

Repair will first calculate the differences, you can see this as a validation 
compaction in nodetool compactionstats.
Then it will stream the data, you can watch that with nodetool netstats. 

Try to work out which part is taking the most time.   15 hours for 50Gb sounds 
like a long time (btw do you have compaction on ?)

Cheers

-
Aaron Morton
Freelance Developer
@aaronmorton
http://www.thelastpickle.com

On 20/05/2012, at 3:14 AM, Raj N wrote:

 Hi experts,
 
 I have a 6 node cluster spread across 2 DCs. 
 
 DC  RackStatus State   LoadOwnsToken

 113427455640312814857969558651062452225
 DC1 RAC13   Up Normal  95.98 GB33.33%  0
 DC2 RAC5Up Normal  50.79 GB0.00%   1
 DC1 RAC18   Up Normal  50.83 GB33.33%  
 56713727820156407428984779325531226112
 DC2 RAC7Up Normal  50.74 GB0.00%   
 56713727820156407428984779325531226113
 DC1 RAC19   Up Normal  61.72 GB33.33%  
 113427455640312814857969558651062452224
 DC2 RAC9Up Normal  50.83 GB0.00%   
 113427455640312814857969558651062452225
 
 They are all replicas of each other. All reads and writes are done at 
 LOCAL_QUORUM. We are on Cassandra 0.8.4. I see that our weekend nodetool 
 repair runs for more than 12 hours. Especially on the first one which has 96 
 GB data. Is this usual? We are using 500 GB SAS drives with ext4 file system. 
 This gets worse every week. This week its even worse, the nodetool repair has 
 been running for the last 15 hours just on the first node and when I run 
 nodetool compactionstats I constantly see this -
 
 pending tasks: 3
 
 and nothing else. Looks like its just stuck. There's nothing substantial in 
 the logs as well. I also dont understand if all these nodes are replicas of 
 each other why is that the first node has almost double the data. Any help 
 will be really appreciated.
 
 Thanks
 -Raj