cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aaron morton <aa...@thelastpickle.com>
Subject Re: Decommissioning node is causing broken pipe error
Date Thu, 05 May 2011 23:53:43 GMT
Could you provide some of the log messages when the receiver ran out of disk space ? Sounds
like it should be at ERROR level. 

Thanks

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

On 6 May 2011, at 09:16, Sameer Farooqui wrote:

> Just wanted to update you guys that we turned on DEBUG level logging on the decommissioned
node and the node receiving the decommissioned node's range. We did this by editing <cassandra-home>/conf/log4j-server.properties
and changing the log4j.rootLogger to DEBUG. 
> 
> We ran decommission again and saw the that the receiving node was running out of disk
space. The 184GB file was not able to fully stream to the receiving node.
> 
> We simply added more disk space to the receiving node and then decommission ran successfully.
> 
> Thanks for your help Aaron and also thanks for all those Cassandra articles on your blog.
We found them helpful.
> 
> - Sameer
> Accenture Technology Labs
> 
> 
> On Thu, May 5, 2011 at 3:59 AM, aaron morton <aaron@thelastpickle.com> wrote:
> Yes that was what I was trying to say. 
> 
> thanks
> -----------------
> Aaron Morton
> Freelance Cassandra Developer
> @aaronmorton
> http://www.thelastpickle.com
> 
> On 5 May 2011, at 18:52, Tyler Hobbs wrote:
> 
>> On Thu, May 5, 2011 at 1:21 AM, Peter Schuller <peter.schuller@infidyne.com>
wrote:
>> > It's no longer recommended to run nodetool compact regularly as it can mean
>> > that some tombstones do not get to be purged for a very long time.
>> 
>> I think this is a mis-typing; it used to be that major compactions
>> were necessary to remove tombstones, but this is no longer the case in
>> 0.7 so that the need for major compactions is significantly lessened
>> or even eliminated. However, running major compactions won't cause
>> tombstones *not* to be removed; it's just not required *in order* for
>> them to be removed.
>> 
>> I think he was suggesting that any tombstones *left* in the large sstable generated
by the major compaction won't be removed for a long time because that sstable itself will
not participate in any minor compactions for a long time.  (In general, rows in that sstable
will not be merged for a long time.)
>> 
>> -- 
>> Tyler Hobbs
>> Software Engineer, DataStax
>> Maintainer of the pycassa Cassandra Python client library
>> 
> 
> 


Mime
View raw message