Hi,

I am running the repair, 
nodetool repair mykeyspace

I do not specify any thing else.

Sent from my iPhone

On 2 May 2013, at 13:17, Yuki Morishita <mor.y...@gmail.com> wrote:

> Hi,
> 
>> ERROR [Thread-12725] 2013-05-01 14:30:54,304 StorageService.java (line 2420) 
>> Repair session failed:
>> 
>> java.lang.IllegalArgumentException: Requested range intersects a local range 
>> but is not fully contained in one; this would lead to imprecise repair
>> 
> 
> This error means you are repairing the range that spreads across multiple 
> (virtual) nodes.
> I think this won't happen unless you specify the repair range with -st and 
> -et option.
> 
> How do you start repair?
> 
> --
> Yuki Morishita
> Sent with Airmail
> On May 2, 2013 at May 2, 2013, Haithem Jarraya (haithem.jarr...@struq.com) 
> wrote:
> 
>> Hi All,
>> 
>>  
>> 
>> Cassandra repair has been a real pain for us and it’s holding back our 
>> migration from mongo for quiet sometimes now.
>> 
>> We saw errors like this during the repair,
>> 
>>  INFO [AntiEntropyStage:1] 2013-05-01 14:30:54,300 AntiEntropyService.java 
>> (line 764) [repair #ed104480-b26a-11e2-af9b-05179fa66b76] mycolumnfamily is 
>> fully synced (1 remaining column family to sync for this session)
>> 
>> ERROR [Thread-12725] 2013-05-01 14:30:54,304 StorageService.java (line 2420) 
>> Repair session failed:
>> 
>> java.lang.IllegalArgumentException: Requested range intersects a local range 
>> but is not fully contained in one; this would lead to imprecise repair
>> 
>>         at 
>> org.apache.cassandra.service.AntiEntropyService.getNeighbors(AntiEntropyService.java:175)
>> 
>>         at 
>> org.apache.cassandra.service.AntiEntropyService$RepairSession.<init>(AntiEntropyService.java:621)
>> 
>>         at 
>> org.apache.cassandra.service.AntiEntropyService$RepairSession.<init>(AntiEntropyService.java:610)
>> 
>>         at 
>> org.apache.cassandra.service.AntiEntropyService.submitRepairSession(AntiEntropyService.java:127)
>> 
>>         at 
>> org.apache.cassandra.service.StorageService.forceTableRepair(StorageService.java:2480)
>> 
>>         at 
>> org.apache.cassandra.service.StorageService$4.runMayThrow(StorageService.java:2416)
>> 
>>         at 
>> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
>> 
>>         at 
>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
>> 
>>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>> 
>>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>> 
>>         at java.lang.Thread.run(Thread.java:662)
>> 
>>  
>> 
>>  
>> 
>> Ok we might have gone beyond the GCGrades(again before repair do not 
>> complete) So we ran scrub  in all node in parallel as it was suggested in 
>> this mailing list.
>> 
>> I am not sure if this can be the cause of the problem or not, but in reality 
>> we had this issue of repair not completing and hanging from the day we 
>> started testing cassandra 1.2.2, same issue happening with every upgrade 
>> 1.2.3 and now 1.2.4.
>> 
>> I want a way to kick in the repair  if they hang or cancel the previous one 
>> without restarting the cluster, we can’t afford to do that the day we go 
>> live.
>> 
>>  
>> 
>> Let me start by presenting our current configuration.
>> 
>> Data Centers:
>> 
>> 2 Data center (Amsterdam 6 nodes with RF of 3, Washington D.C with RF of 1)
>> 
>> 1 Key space with 3 column families ~= 100GB of data.
>> 
>> Each node running Cassandra 1.2.4 with Java6_update45 running centos 2.6 
>> with 32GB of RAM, 24 Cores @2.00GHZ, JNA v3.2.4 installed, 2 disk( 1 
>> rotational for os and commit logs, and 1 ssd for the data). We are getting 
>> really good read performances, 99% < 10ms,  95% < 5ms.
>> 
>>  
>> 
>> nodetool status
>> 
>> Datacenter: ams01
>> 
>> =================
>> 
>> Status=Up/Down
>> 
>> |/ State=Normal/Leaving/Joining/Moving
>> 
>> --  Address       Load       Tokens  Owns   Host ID                          
>>      Rack
>> 
>> UN  x.x.x.23   34.04 GB   256     13.1%  
>> 4a7bc489-25af-4c20-80f8-499ffcb18e2d  RAC1
>> 
>> UN  x.x.x.79    28.53 GB   256     12.6%  
>> 98a1167f-cf75-4201-a454-695e0f7d2d72  RAC1
>> 
>> UN  x.x.x.78    41.31 GB   256     11.9%  
>> 62a418b5-3c38-4f66-874d-8138d6d565e5  RAC1
>> 
>> UN  x.x.x.66   54.41 GB   256     13.8%  
>> ab564d16-4081-4866-b8ba-26461d9a93d7  RAC1
>> 
>> UN  x.x.x.91    45.92 GB   256     12.6%  
>> 2e1e7179-82e6-4ae6-b986-383acc9fc8a2  RAC1
>> 
>> UN  x.x.x.126  37.31 GB   256     11.8%  
>> d4bed3b1-ffaf-4c68-b560-d270355c8c4b  RAC1
>> 
>> Datacenter: wdc01
>> 
>> =================
>> 
>> Status=Up/Down
>> 
>> |/ State=Normal/Leaving/Joining/Moving
>> 
>> --  Address       Load       Tokens  Owns   Host ID                          
>>      Rack
>> 
>> UN  x.x.x.144   30.64 GB   256     12.0%  
>> 1860011e-fa7c-4ce1-ad6b-c8a38a5ddd02  RAC1
>> 
>> UN  x.x.x.140   86.05 GB   256     12.3%  
>> f3fa985d-5056-4ddc-b146-d02432c3a86e  RAC1
>> 
>>  
>> 
>> nodetool  status mykeyspace
>> 
>> Datacenter: ams01
>> 
>> =================
>> 
>> Status=Up/Down
>> 
>> |/ State=Normal/Leaving/Joining/Moving
>> 
>> --  Address       Load       Tokens  Owns (effective)  Host ID               
>>                 Rack
>> 
>> UN  x.x.x.66   54.41 GB   256     53.6%             
>> ab564d16-4081-4866-b8ba-26461d9a93d7  RAC1
>> 
>> UN  x.x.x.91    45.92 GB   256     52.1%             
>> 2e1e7179-82e6-4ae6-b986-383acc9fc8a2  RAC1
>> 
>> UN  x.x.x.126  37.31 GB   256     47.9%             
>> d4bed3b1-ffaf-4c68-b560-d270355c8c4b  RAC1
>> 
>> UN  x.x.x.23   34.04 GB   256     50.9%             
>> 4a7bc489-25af-4c20-80f8-499ffcb18e2d  RAC1
>> 
>> UN  x.x.x.79    28.53 GB   256     47.4%             
>> 98a1167f-cf75-4201-a454-695e0f7d2d72  RAC1
>> 
>> UN  x.x.x.78    41.31 GB   256     48.0%             
>> 62a418b5-3c38-4f66-874d-8138d6d565e5  RAC1
>> 
>> Datacenter: wdc01
>> 
>> =================

Reply via email to