incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sameer Farooqui <cassandral...@gmail.com>
Subject Re: Decommissioning node is causing broken pipe error
Date Thu, 05 May 2011 21:16:36 GMT
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 <http://datastax.com/>
> Maintainer of the pycassa <http://github.com/pycassa/pycassa> Cassandra
> Python client library
>
>
>

Mime
View raw message